tcp协议简介

tcp报文
     1.面向连接的
     2.可靠地
     3.通过字节流传输数据
     4.全双工的

tcp协议的报文格式:

tcp必知必会1:由什么唯一确定一条tcp?
     一条tcp是由(源端:ip+端口)+(目的端:ip+端口)唯一确定.
    
tcp建立连接(三次握手):
     1.由客户端发送一个SYN报文,客户端消耗一个序号.
     2.服务器段发送一个应答报文(ACK)+SYN(请求报文),服务器端消耗一个序号.
     3.客户端响应服务器的SYN报文,不消耗序号
     综上,完成一次三次握手,服务器和客户端各消耗掉一个序号.

三次握手如图:

注意:在三次握手过程中,会协商MSS.

tcp必知必会2:什么是MTU和MSS?
     MTU:链路层最大传输单元.链路层传输数据的大小有一个上限,超过这个上限就会造成ip分片,使得传输效率下降.
     MSS:最大报文段长度.表示传往另一端的最大报文段长度,如果大于MSS的值报文就要进行分段,一般而言,报文越大传输效率要高.

tcp必知必会3:为什么必须要三次握手,而两次不可以?
     如果tcp两次握手:正常情况下,客户端发送一个SYN,服务器收到并发送一个SYN+ACK,客户端收,双方建立连接.
     我们假设这么一种情况:客户端第一次发送的SYN在网络上发生延迟,客户端没有按时收到ACK,会进行重发.当第二次发送的SYN被服务器端收到并发送ACK,两个建立连接,过一段时间,客户第一次发送的SYN神奇的到达了服务器端,而服务器发送了一个ACK+SYN,服务器认为建立连接,而客户端收到一个莫名其妙的ACK,丢弃,没有建立连接,这样就造成了服务器的单向链接,浪费资源.

tcp释放连接(四次挥手):
     1.主动关闭端发送一个FIN(进入FIN_WAIT1状态),消耗一个序号
     2.被动关闭端收到FIN,发送一个ACK(进入CLOSE_WAIT状态)
     3.主动关闭端收到ACK(进入FIN_WAIT2状态)
     4.被动关闭端发送一个FIN(进入LAST_ACK状态),消耗一个序号
     5.主动关闭端收到一个FIN,并发送ACK(进入TIME_WAIT状态)
     6.被动关闭端收到一个ACK,进入CLOSED状态.

tcp必知必会4:MSL和TTL
     MSL:tcp报文在网络传输中最大的生存时间.
     TTL:IP报文在网络传输中最大的生存时间.

tcp必知必会5:2MSL
     为了防止最后一个FIN的ACK丢失,必须要求主动关闭端至少等待2MSL时间,以备重发.
     在2MSL时间内,这条tcp连接(源ip+端口,目的ip+端口)不能重用.
    
tcp必知必会5:平静时间
     为了防止一条重启的tcp连接接受来自较早连接(同一个socket对)的报文,在该tcp重启后MSL时间内不允许建立任何连接.

RST复位报文段:
     1.当tcp建立连接时候,目的端口没有进程在监听,目的端就会发送一个复位报文段,tcp连接建立失败
     2.当异常终止一个连接时候会发送RST报文段.RST发送方会立即丢弃所有待发送报文,并发RST报文.接收方会区分另一方是正常关闭还是异常关闭.

     3.RST导致连接终止.

同时打开和同时关闭这里不进行赘述,他们与正常打开和关闭差别不大.

保活定时器与半打开连接:
     为了防止半打开连接,服务器一端通常要设定一个定时器,如果在一段时间内tcp连接双方没有任何数据交换,则发送一个探查报文,查看连接是否正常.

坚持定时器:
     在tcp传输过程中,并不会对ack进行确认.当传输过程中,如果接收端在ack时设定窗口为0,则发送端会一直等待一个重复确认,设置窗口不为零才再次进行数据传输.如果重复确认丢失,会造成死锁,发送端一直等待窗口更新,接受端一直等待接收数据.
     这时候坚持定时器出场了,当发送端窗口设置为0时候,发送端会设置一个坚持定时器,当定时器到时时候,仍然没有窗口更新,则发送一个探查报文.
     

糊涂窗口综合征
     1.发送方发送报文长度太小,使得传输效率不高.
     2.接收方总通知小窗口,而不是等待接收窗口达到一定程度才通知
  解决方法:
     我们可以任意改变以上两个条件中的一个来阻止糊涂窗口现象
     1.接收方等到窗口至少可以容纳一个MSS才进行通告.
     2.发送方可以等到数据累计到至少a)一个满长度报文 b)对方通告窗口一半大小的报文 c)没有未被确认的数据或该连接上不适用Nagle算法.

Nagle算法:
     在tcp连接上最多只能有一个未被确认的分组,该分组的确认到达之前不能发送其他分组.
   优点:
     该算法是自适应的,确认的越快,发送的越快,有效的避免了网络拥塞.

停等协议:

     发送端每次发送一个分组并保留分组的副本,设置超时定时器,等待确认.
     若接收端接收到数据,发送确认,发送端接收到确认再进行发送下一个分组.
  出错情况:
     1.接收端未接收到数据,发送端定时器超时,重新发送.
     2.发送端接收到数据,发送确认,确认丢失,发送端重发数据,接收端丢弃,进行重复确认.

连续ARQ协议(自动重传请求协议):
     发送端维持一个发送窗口,发送端仅仅发送窗口内的数据.当收到确认时窗口向前滑动.
     接收端接受来自发送端的数据,仅仅对按需到达的最后一个分组进行确认.
     当一个中间分组丢失时候,要退回N步重传.

滑动窗口:
     发送端维持一个发送窗口,仅发送窗口内的数据,等到确认到达时窗口向前滑动
     接收端维持一个接受窗口,仅仅接受窗口内的数据,对按序收到的最后一个分组进行确认,并向前滑动窗口.并且在发送确认的时候总是通知接收窗口可接收数据大大小.

定时器设置:
     首先我们要计算报文的往返时间:RTT,然后设置重传时间:RTO
     RTTs:平滑往返时间.
     RTTs = (1-a)(旧的RTTs)+a*(RTT样本)   a一般取值1/4
     其中a为权重,反应RTTs受新来的样本影响的大小.当a取较大的值时候,说明样本对     RTTs影响较大.
     RTO = RTTs +4*RTTd
     在第一次计算时候RTTd为RTTs的一半,以后用以下公式计算:
     RTTd = (1-B)*(旧的RTTd) + B*|RTTs-新的RTT样本|  B 一般取值1/4
     RTTd反映了RTTs和新样本的偏差
  问题:
     当一个报文因为超时而重传,收到了两个确认报文,这时候计算RTT就会不同.
     如果计算重传报文的往返时间,会造成RTT偏大或者偏小.一般不对重传报文计算往返时间.

拥塞控制
      慢启动+拥塞避免:
     慢启动:发送端窗口初始值设置为1,然后每一个轮次(发送分组并收到确认)翻倍.
     拥塞避免:cwind每次+1;
     慢启动+拥塞避免:
         1.当cwind<ssthresh时候使用慢开始算法
         2.当cwind==ssthresh时候使用拥塞避免算法
         3.当网络发生拥塞(超时),把ssthresh设置为当前cwind的一般,令cwind=1,并执行1

     缺点: 每次cwind都要从1开始计算,网络利用率不高.

      快重传+快恢复

     快重传:接收方每当收到一个失序报文就发送一个确认,发送端每当收到三个连续的重复确认时,就重传报文
     快恢复:当网络发生拥塞时(发生报文重传),就把ssthresh设为cwind的一般,cwind减半,执行拥塞避免算法.