HCIA第二次作业—— tcp阻塞控制，滑动窗口，http状态码，Nslookup

将tcp阻塞控制，滑动窗口等机制了解清楚，以及课堂上布置的其他作业一并提交上来

1.TCP阻塞控制

TCP阻塞控制是TCP实现可靠传输的其中一个手段

为什么会产生TCP的阻塞呢？

        其实就是发送端发送的报文速度要接收端大。这样就会造成网络阻塞的问题，如果不使用一定手段进行控制，就会造成死锁。

TCP拥塞控制能够提高网络利用率，降低丢包率，并保证网络资源对每条数据流的公平性。拥塞控制主要有几种：慢启动，阻塞避免，快速重传 以及 快速恢复。

（1）慢启动

        对发送数据量进行控制，为了调节发送端的数据发送量，引入了拥塞窗口，在慢启动时，将这个拥塞窗口设为1个报文段发送数据。之后每收到一次确认应答，拥塞窗口就加１和报文段。在发送数据包时，将拥塞窗口的大小与接收端主机通知的窗口大小进行比较，然后选择较小的值来控制数据量的发送。拥塞窗口是发送端使用的流量控制，而通告窗口则是接收端使用的流量控制。
　　慢启动算法的步骤如下(cwnd全称Congestion Window):
　　1.初始化cwnd=1，表示可以传一个MSS大小（最大传输单元1460字节）的数据；
　　2.每收到一个ACK，cwnd++，即增加１，呈线性上升；
　　3.每当过了一个RTT，cwnd = cwnd * 2，呈指数上升；
　　4.ssthresh(slow start threshold 慢开始门限)，是一个上限，当cwnd>=ssthresh时，就会进入拥塞避免算法。

（2）阻塞避免

        拥塞避免算法是让拥塞窗口缓慢地增大，收到每一轮的确认后，将拥塞窗口的值加1，而不是加倍，这样拥塞窗口的值按照线性规律缓慢增长。在慢启动中，当cwnd>=ssthresh时，就会进入“拥塞避免算法”。一般来说ssthresh的值是65535，单位是字节，当cwnd达到这个值后，算法如下：
　　１．收到一个ACK时，cwnd=cwnd+ 1/cwnd;
　　２．当过一个RTT时，cwnd=cwnd+1;

（3）快速重传和快速恢复

块重传算法要求接收方每收到一个失序的报文段后就立即发出重复确认(重复发送对前面有序部分的确认)，而不是等到自己发送数据时才进行捎带确认，也不是累计收到的报文发送累计确认，如果发送方连续收到三个重复确认，就应该立即重传对方未收到的报文段(有收到重复确认，说明后面的报文段都到达了，只有中间丢失的报文段没送达)。

　　快恢复算法与快重传算法配合使用：

　　１．当发送方连续收到三个重复确认（ACK）时，就把慢开始门限ssthresh设置为当前拥塞窗口cwnd的一半，重传丢失的报文段。设置cwnd为ssthresh加上三倍的报文段大小；
　　２．每次收到另一个重复的ACK时，cwnd增加１个报文段大小并发送１个分组；
　　３．当下一个确认新数据的ACK到达时，设置cwnd为ssthresh(跟第１步一样设置方法)。这个ACK应该是在进行重传之后的一个往返时间内对步骤１中重传的确认。另外，这个ACK也应该是对丢失的分组和收到额第一个重复的ACK之间的中间报文段的确认。这一步采用的是拥塞避免算法。

2.滑动窗口

        滑动窗口实现了TCP流控制。首先明确滑动窗口的范畴：TCP是双工的协议，会话的双方都可以同时接收和发送数据。     TCP会话的双方都各自维护一个发送窗口和一个接收窗口。

发送方的发送缓存内的数据都可以被分为4类:
1. 已发送，已收到ACK
2. 已发送，未收到ACK   ——>   发送窗口
3. 未发送，但允许发送   ——>   发送窗口
4. 未发送，但不允许发送

接收方的缓存数据分为3类：
1. 已接收
2. 未接收但准备接收      ——>    接收窗口
3. 未接收而且不准备接收

窗口大小代表了设备一次能从对端处理多少数据，之后再传给应用层。缓存传给应用层的数据不能是乱序的，窗口机制保证了这一点。现实中，应用层可能无法立刻从缓存中读取数据。

滑动机制

1.发送窗口只有收到发送窗口内字节的ACK确认，才会移动发送窗口的左边界。

2.接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。

3.遵循快速重传、累计确认、选择确认等规则。

4.发送方发的window size = 8192;就是接收端最多发送8192字节，这个8192一般就是发送方接收缓存的大小.

3.https中301 302 307 308重定向的区别

GET和POST都是浏览器或客户端与服务器通信的方法，简而言之，GET就是浏览器向服务器请求特定数据，POST将数据提交给要处理的服务器。

GET请求会被缓存  POST请求不会被缓存

临时 ——————301 为永久移动            308 为永久重定向      

永久 ——————302为发现                    307 为临时重定向

301和302本来在规范中是不允许重定向时改变请求方法的（将POST改为GET），但是许多浏览器却允许重定向时改变请求方法（这是一种不规范的实现）。

307和308的出现也是给上面的行为做个规范，是不允许重定向时改变请求方法

301 Moved Permanently（永久移动）

被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个URI之一。如果可能，拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。新的永久性的URI应当在响应的Location域中返回。除非这是一个HEAD请求，否则响应的实体中应当包含指向新的URI的超链接及简短说明。如果这不是一个GET或者HEAD请求，因此浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。注意：对于某些使用HTTP/1.0协议的浏览器，当它们发送的POST请求得到了一个301响应的话，接下来的重定向请求将会变成GET方式。

302 Found（发现）

要求客户端执行临时重定向。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。新的临时性的URI应当在响应的Location域中返回。除非这是一个HEAD请求，否则响应的实体中应当包含指向新的URI的超链接及简短说明。如果这不是一个GET或者HEAD请求，那么浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。

307 Temporary Redirect（临时重定向）

与302相似，但是 当重新发出原始请求时，不允许更改请求方法。 例如，应该使用另一个POST请求来重复POST请求

308 Permanent Redirect （永久重定向）

 307和308重复302和301的行为，但不允许更改请求方法（即HTTP方法更改）。 例如，将表单提交给永久重定向的资源可能会顺利进行

4.Nslookup命令研究，详解

（1）nslookup作用

nslookup用于查询DNS的记录，查询域名解析是否正常，在网络故障时用来诊断网络问题

1>直接查询 nslookup domain [dns-server] 

 //如果没有指定dns服务器，就采用系统默认的dns服务器。

2>查询其他记录      nslookup -qt = type domain [dns-server]
type:
    A -->地址记录
    AAAA   -->地址记录
    AFSDB Andrew    -->文件系统数据库服务器记录
    ATMA -->ATM地址记录
    CNAME   -->别名记录
    HINHO  -->硬件配置记录，包括CPU、操作系统信息 
    ISDN   -->域名对应的ISDN号码
    MB   -->存放指定邮箱的服务器
    MG    -->邮件组记录
    MINFO   -->邮件组和邮箱的信息记录
    MR   -->改名的邮箱记录
    MX   -->邮件服务器记录
    NS  --> 名字服务器记录
    PTR    ->反向记录
    RP    -->负责人记录
    RT  -->路由穿透记录
    SRV    -->TCP服务器信息记录
    TXT   -->域名对应的文本信息
    X25  -->域名对应的X.25地址记录

3>查询更具体的信息

nslookup -d [其他参数] domain [dns-server]

//只要在查询的时候，加上-d参数，即可查询域名的缓存