TCP/IP协议 之一

最近在做一些网络通讯方面的程序，对通讯机制的可靠性控制，流量控制方面破为恼火。
于是又看了看TCP方面的内容，希望能从中获得些启发。尽管这些很久前学过，而且学了不止一次，但以前的理解都比较浮浅，而且实际的协议实践很少，所以，理解并不深刻，感觉。现在再看看，希望能有些新的理解与想法。
下面的是内容主要来自一位老师的课堂PPT与<用TCP/IP进行网际互联，第一卷，原理、协议与结构>一书，两者整理而得。仅为学习。

1 TCP目的：弥补UDP协议的不足，屏蔽与网络有关的故障和错误，为网络进程提供可靠通讯

2 特点

全双工通讯、Piggybacking（捎带方式）
面向数据流、无结构数据流
虚电路连接：面向连接、三次握手
流量控制、差错控制、拥塞控制
滑动窗口

提供的服务：
 流式数据服务
    1) 发送和接受，TCP都使用缓存
    2) 应用进程发送的数据首先保留在TCP发送缓存中，当数据量达到一个报文段大小时，TCP就向外发送数据。
    3) 应用进程的多个发送请求，可能对应一个TCP数据发送；
    4) 可以使用PUSH机制使应用进程的每个发送请求都对应一个TCP数据发送；
    5) TCP收到保文后存放在接收缓存中，等待应用进程读取；
    6) 一个TCP发送可以对应多个TCP读操作；多个TCP发送可以对应一个读操作。
 全双工服务
      1) 数据可以同时双向传输
      2) 确认信息可以通过数据段报文捎带。
 可靠服务
      1) 采用确认机制确保数据发送成功
      2) 采用给报文编号消除重复报文

3 TCP报文说明

序    号：已发送数据的最大序号(A发送给接收方B)
确认号：已接收的数据的最小序号+1(B发送给A)
特殊比特：
(1)   URG : 紧急比特，带外数据
       URG=1;紧急指针起作用，该指针指明紧急数据在数据流中的结束位置
(2)   ACK : 确认比特
        ACK=1;确认号有意义；否则无意义
(3)   PSH  : 立即发送比特
        PSH=1;报文采用PUSH技术传送
(4)   RST  : 复位比特
        RST=1;重建连接
(5)   SYN :  同步比特
        SYN=1且ACK=0;则该报文是一个连接请求。对方若同意建立连接，则返回报文的SYN、ACK均置1
(6)   FIN   :  终止比特
        请求释放运输连接

校验和：
采用和UDP相同的伪首部机制来计算校验和
UDP的校验和是可选的；TCP的校验和是必须的；
TCP校验和的作用与UDP是一样的。

TCP选项最多40个字节

4 TCP提供可靠通信的机理
问题
      底层协议不可靠、高层协议如何可靠
      产生的问题：报文丢失、出错、延迟、失序
(2) 解决办法
      1）报文出错：差错控制
      2）报文丢失、出错：确认、重传
      3）报文延迟：报文丢失假象：重传
                                消除重复报文(报文编号)
      4）报文失序：依序接受
      5）收发同步、协调：流控机制，滑动窗口   

5 流量控制
作用
        由于发送速率可能大于接收速率、接收缓冲区不是足够大不能缓存所有接收到的报文、接收端的应用进程未能及时从接收缓冲区读取数据等原因，TCP接收端的接收缓冲区很快就会充满；从而造成不能接收后续的数据，发送端此时发送数据也是不必要的，因此需要流控。
        流控主要解决TCP发送端和接收端间的速率匹配；即如何根据接收端的当前接收能力来调整发送端的发送速率。

(2) 解决机制
    可变滑动窗口机制
发送端滑动窗口的含义
(5) TCP 滑动窗口的特点
      1) 源端不一定要把滑动窗口中的数据全部发送出去
        2) 源端滑动窗口大小可由接收端控制，可增大、减少
        3) 接收端在任何时候均可发送确认，以捎带其希望的窗口大小
(6) TCP滑动窗口实例
　 1) 若A、B两个主机上的应用进程通过TCP通信； 一方向对方传送5k数据
   2) A端应用进程作为发送端、B端应用进程作为接收端；
      连接建立时，对应该连接的A端TCP的发送缓冲区为8K;
                  对应该连接的B的接收缓冲区为4K；
      连接建立时，B端TCP通告A端TCP，其窗口大小为4K
   3) A端TCP发送完4K数据后，等待确认；
   4) B端TCP收到4K数据后，通告A端TCP其窗口大小为0；
   5) A端收到确认通告后，不发送数据(窗口不滑动、调整)；
   6) B端应用进程取走1.5K数据后，发确认通告，且窗口大小为1.5K
   7) A端窗口窗口向前滑动4K，且把窗口大小调整为1.5K;
      并发送剩下的1K数据；
糊涂窗口综合症
什么是糊涂窗口综合症？
            当发送端应用进程产生数据很慢、或者接收端应用进程处理数据接收缓冲区数据很慢，或者二者兼而有之；就会使应用进程间传送的报文段很小，特别是有效载荷很小。
               极端情况下，有效载荷可能只有1个字节；而传输开销有40字节(20字节的IP头+20字节的TCP头)
               这种现象就叫糊涂窗口综合症

6 糊涂窗口综合症类别
      两大类
        发送端引起的糊涂窗口综合症，象Telnet应用；
        接收端引起的糊涂窗口综合症

(1) 窗口通告
接收端使用确认数据段的 WINDOW 字段来对发送端告知目前有多少可用的缓冲区。
(2) 问题：糊涂窗口综合症 (silly window syndrome)
每一确认只告知少量的可用空间，且每一数据段携带很小的数据量。
(3) 举例说明
若接收端的接收缓冲区已满，窗口通告 WINDOW = 0。
若接收端进程从缓冲区取走1个字节，则窗口通告
     WINDOW = 1。
则发送端可能会传送拥有一个字节的数据段。
传送小数据段会浪费不必要的网络带宽和不必要的计算开销。

接收端糊涂窗口综合症-解决办法
接收端有2种的方法：

(1) 延迟通告 (Delayed Advertisement)---Clark法
TCP对到达的数据报立即做出确认。
在送出一个窗口大小为0通告之后，至少需要等待缓冲区的可用空间达到其全部的 50% 或是达到最大尺寸的数据段 (maximum sized segment，MSS)再发通告。
(2) 推迟确认 (Delayed Acknowledgement)
标准建议使用「推迟确认」
TCP 推迟传送确认消息，直到窗口大小达到一定的量才通告窗口的可用量。
优点：降低数据量、 提高吞吐率
缺点： 不必要的重传、 造成估算往返时间的的混淆
 解决办法
推迟确认的时限 (500ms).
至少每隔一个数据段就应该确认。

发送端糊涂窗口综合症-解决办法
1) 目标
避免传送小数据段
(2) 组块技术 (Clumping)
发送端TCP在数据段发送之前必须延迟，直到聚集了足够的数据。
问题：
TCP应该等待多久才能发送数据？
若太久 ? 高延迟
若太短 ? 小数据段、低效率
解决办法：
1) 固定延迟
不能区分传送按键和传送数据这两种情况？
非最佳化
2) Nagle演算法： 自适应的延迟
算法：
    1) 发送端TCP将从应用进程接收到的第一数据块立即发送，不管其大小，哪怕只有一个字节
   2) 发送端输出第一数据后开始收集数据，并等待确认；
   3) 在确认未达到时，
            若收集数据达到窗口的一半或达到一个MSS段，立即发送
    3  确认到达，把缓冲区中的数据组成一个TCP段，然后发送

        很小的计算开销
       不需对不同的连接维持不同的计时器
       生成数据时不需检查时钟
       可适应任意的网络延迟、最大数据段尺寸、和应用进程的组合情况。

7、TCP确认与重传机制
累计确认
      确认针对数据流中的数据，不是报文段
优点
       1）无二义性；
       2）确认丢失不一定会引起重传
(3) 实例:A向B发送数据
    1)设发送端窗口为{1201,2000}；分2报文段传送；
    2)第一个报文段{1201,1600},第二个报文段{1601,2000};
      B首先发回确认{1601}，再发回确认{2001}
    3)若A在定时器未到之前只收到确认{2001}，而{1601}丢失，则A不会重传{1201,1600}报文段；       

超时与重传
TCP环境
      报文往返时间不定、有很大差别
        A、B在一个局域网络，往返时间很小
        A、C在一个互联网内，往返时间很大
       因此，A很难确定一个固定的、与B、C通信都适用的定时器时间
(2) TCP超时重传机制
      自适应重传算法
      定时器是与连接相关的

定时器时间是由报文段的平均往返时间确定的
        TimeOut=B*RTT(Round Trip Time)

RTT的确定
        某个报文段的 RTT=收到确认的时间-发送的时间
        平均RTT=a*Old_RTT+(1-a)*New_RTT
         a接近于1的含义：时间不敏感型
         a接近于0的含义：实间敏感型

累计确认造成RTT在重传机制下是很不精确的
RTT的Karn补偿方法
基本出发点
      1) 不用重传报文，不用估算其RTT
      2) 当然就不用重传报文的RTT来修正定时器的Timeout值
(2) 发生重传时，增加Timeout
      New_Timeout=r*Old_Timeout
(3) Timeout不会无限增加，受上限约束
(4) 无重传时，重新估算Timeout值

TCP的四种定时器
重传定时器： 用于报文丢失
        丢失报文重传需要等待的时间  
 
保活定时器：用于确保TCP连接有效
        例如：客户进程和服务器建立了一个连接，客户传输了一些数据后，长时间静默；服务器如何知道客户进程还处于工作状态？
        解决办法：
        1) 服务器为每个连接设置一个保活定时器(2小时)；
        2) 若收到客户报文，就将定时器复位；
        3) 一旦定时器时间到，还没收到客户报文，就发探测报文，若多次探测(10)后没有结果，就断开连接
(3) 坚持定时器:用于流控中的零窗口大小通告
    问题：若接收端向发送端通告了零窗口大小，则发送端就会一直等待接收端的非零窗口通告；
     此时，若接收端的非零窗口通告丢失，则发送端就一直等待，接收端也一直等待发送端发送新的数据；
     这样，系统就会死锁。
     解决办法：
       1) 发送端收到非零通告后，就启动坚持定时器；
       2) 在定时器未到时，就收到非零通告，则关闭该定时器；   
     3) 若定时器已到，还没有收到非零通告，就发探测报文；
       4) 若发送端未收到对探测报文的相应，就将坚持定时器的值加倍且复位；重复多次，直至出错或收到响应。

(4) 时间等待定时器：用于连接中止
     具体见TCP连接的关闭过程；
     1) TCP关闭一个连接时，并不马上认为这个连接关闭了；而是使之处于一种过渡状态;该定时器用于表明该过渡状态的时间长短；
     2）在定时器到时，收到预期报文，就真正关闭该连接；
        否则，重新进行连接关闭；多次后，强行关闭连接；

8、TCP拥塞控制
拥塞 (Congestion)
拥塞是因为报文在一个或多个路由器发生过栽而导致严重延迟
一旦发生拥塞，延迟显著增加，路由器开始将报文缓存起来，直到它有能力将其发送出去。
最坏情况下，到达拥塞路由器的报文持续增加到超过器存储能力，此时路由器就丢弃 (discard)报文。
拥塞发生时的表现
      报文传送时延增加、使得定时器超时
(2) 在拥塞情况下，定时器超时重传会加重拥塞
      直至网络瘫痪
(3) TCP拥塞处理策略
      1）假设报文丢弃大多数都是拥塞引起的
      2）加速递减机制：发生拥塞时的抑制机制：指数递减-〉1
     3）慢启动：拥塞解除时的恢复机制：指数增加
     4）拥塞避免：避免慢起动窗口增长过大的机制
            恢复：指数增加-〉线性增加

发送窗口=min(通知窗口，拥塞窗口)
通知窗口：接收方可接收数据量的大小
拥塞窗口：最大值=通知窗口
加速递减策略：发生报文丢失时的策略
      拥塞窗口成倍减少、按2的倍数减少
(5) 慢起动策略：拥塞恢复时的策略
       拥塞窗口成倍增加，按2的倍数增加