17 tcp

1、TCP首部

每个TCP段都包含源端和目的端的端口号，用于寻找发端和收端应用进程。这两个值加上IP首部中的源端IP地址和目的端IP地址唯一确定一个TCP连接

序号 用来标识从TCP发端向TCP收端发送的数据字节流，它表示在这个报文段中的的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动，则TCP用序号对每个字节进行计数。序号是32 bit的无符号数，序号到达 2^23－ 1后又从0开始。
窗口大小 流量控制
检验和 覆盖tcp首部和tcp数据

2、TCP连接的建立与终止

2.1 三次握手

第一次握手:
客户端发送一个TCP的SYN标志位置1的包指明客户打算连接的服务器的端口，以及初始序号X,保存在包头的序列号(Sequence Number)字段里。
第二次握手:
服务器发回确认包(ACK)应答。即SYN标志位和ACK标志位均为1同时，将确认序号(Acknowledgement Number)设置为客户的I S N加1以.即X+1。
第三次握手.
客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段中发送给对方.并且在数据段放写ISN的+1

发送第一个SYN的一端将执行主动打开
接收SYN并发回下一个SYN的另一端将被动打开

2.2 四次挥手

客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送。
服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号。
服务器B关闭与客户端A的连接，发送一个FIN给客户端A。
客户端A发回ACK报文确认，并将确认序号设置为收到序号加1。

2.3 连接超时的情况

连接会不断重试，直到超时。一般超时时间为75秒

2.4 TCP的半关闭

TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。这就是半关闭。
close将完全关闭。
shutdown(int sockfd, int how); how=(SHUT_RD or SHUT_WR or SHUT_RDWR)

2.5 TCP状态

CLOSED：初始状态，表示TCP连接是“关闭着的”或“未打开的”。
LISTEN ：表示服务器端的某个SOCKET处于监听状态，可以接受客户端的连接。
SYN_RCVD ：表示服务器接收到了来自客户端请求连接的SYN报文。在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat很难看到这种状态，除非故意写一个监测程序，将三次TCP握手过程中最后一个ACK报文不予发送。当TCP连接处于此状态时，再收到客户端的ACK报文，它就会进入到ESTABLISHED 状态。
SYN_SENT ：这个状态与SYN_RCVD 状态相呼应，当客户端SOCKET执行connect()进行连接时，它首先发送SYN报文，然后随即进入到SYN_SENT 状态，并等待服务端的发送三次握手中的第2个报文。
SYN_SENT 状态表示客户端已发送SYN报文。
ESTABLISHED ：表示TCP连接已经成功建立。
FIN_WAIT_1 ：这个状态得好好解释一下，其实FIN_WAIT_1 和FIN_WAIT_2 两种状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET进入到FIN_WAIT_1 状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2 状态。当然在实际的正常情况下，无论对方处于任何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1 状态一般是比较难见到的，而FIN_WAIT_2 状态有时仍可以用netstat看到。
FIN_WAIT_2 ：上面已经解释了这种状态的由来，实际上FIN_WAIT_2状态下的SOCKET表示半连接，即有一方调用close()主动要求关闭连接。注意：FIN_WAIT_2 是没有超时的（不像TIME_WAIT 状态），这种状态下如果对方不关闭（不配合完成4次挥手过程），那这个 FIN_WAIT_2 状态将一直保持到系统重启，越来越多的FIN_WAIT_2 状态会导致内核crash。
TIME_WAIT ：表示收到了对方的FIN报文，并发送出了ACK报文。 TIME_WAIT状态下的TCP连接会等待2*MSL（Max Segment Lifetime，最大分段生存期，指一个TCP报文在Internet上的最长生存时间。每个具体的TCP协议实现都必须选择一个确定的MSL值，RFC 1122建议是2分钟，但BSD传统实现采用了30秒，Linux可以cat /proc/sys/net/ipv4/tcp_fin_timeout看到本机的这个值），然后即可回到CLOSED 可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。（这种情况应该就是四次挥手变成三次挥手的那种情况）
CLOSING ：这种状态在实际情况中应该很少见，属于一种比较罕见的例外状态。正常情况下，当一方发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。但是CLOSING 状态表示一方发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？那就是当双方几乎在同时close()一个SOCKET的话，就出现了双方同时发送FIN报文的情况，这是就会出现CLOSING 状态，表示双方都正在关闭SOCKET连接。
CLOSE_WAIT ：表示正在等待关闭。怎么理解呢？当对方close()一个SOCKET后发送FIN报文给自己，你的系统毫无疑问地将会回应一个ACK报文给对方，此时TCP连接则进入到CLOSE_WAIT状态。接下来呢，你需要检查自己是否还有数据要发送给对方，如果没有的话，那你也就可以close()这个SOCKET并发送FIN报文给对方，即关闭自己到对方这个方向的连接。有数据的话则看程序的策略，继续发送或丢弃。简单地说，当你处于CLOSE_WAIT 状态下，需要完成的事情是等待你去关闭连接。
LAST_ACK ：当被动关闭的一方在发送FIN报文后，等待对方的ACK报文的时候，就处于LAST_ACK 状态。当收到对方的ACK报文后，也就可以进入到CLOSED 可用状态了。

2.6 2MSL

每个具体TCP实现必须选择一个报文段最大生存时间MSL。它是任何报文段被丢弃前在网络内的最长时间。
TIME_WAIT状态也称为2MSL等待状态。
协议规定主动关闭一方，进入FIN_WAIT_2->TIME_WAIT，必须等待2MSL（MSL为最大报文段生存时间，LWIP为1分钟，windows为2分钟）时间然后才进入CLOSED，删除TCP控制块。在2MSL等待时间内迟到的报文段将被抛弃。
2MSL等待的原因：报文段有生存时间，当连接关闭时，有可能收到迟到的报文段。这时，若立马就建立新的连接（同一端口），那么新的连接就会接收迟到的报文，误以为是发给自己的。另一个原因是可靠的实现全双工连接的终止。

2.7 复位报文段

TCP首部中的RST比特是用于“复位”的。一般说来，无论何时一个报文
段发往基准的连接出现错误，TCP都会发出一个复位报文段。
http://blog.csdn.net/nestler/article/details/25736131
2.7.1 到不存在的端口的连接请求
当一个数据报到达目的端口时，该端口没在使用，客户端发送SYN包到一个未知端口，然后收到一个RST包。

2.7.2 异常终止一个连接
当不想通过发送FIN正常关闭连接时，可以发送RST包给对方。发送方丢弃任何数据并立即发送复位报文段。接收方收到后直接关闭连接，不发送确认包。

2.7.3 检测半打开连接
如果一方已经关闭或异常终止连接而另一方却还不知道，这种连接称为半打开的。只要不在半打开的连接上传输数据，仍处于连接状态的一方就不会检测另一方已经出现异常。
当出现异常的一方恢复正常并且继续收到来自另一方的数据（另一方并不知道这边的情况），这是接收方无法辨认接受的数据是什么，于是发送复位报文段作为应答。

3、TCP的交互数据流

3.1 确认的时延

通常TCP在接收到数据时并不立即发送ACK，相反，它推迟发送，以便将ACK与需要沿该方向发送的数据一起发送（有时这种现象为数据捎带的ACK）。绝大数实现采用的时延为200ms，也就是说，TCP将以最大200ms的时延等待是否有数据一起发送。

3.2 Nagle算法

Nagle算法要求TCP连接上最多只有一个未被确认的未完成小分组，在该分组确认到达之前不能发送其他的小分组。相反，TCP收集这些少量的分组，并在确认到达时以一个大的分组发出去。
该算法的优点在于它是自适应的：确认到达得越快，数据也就发送得越快。可以减少网络上的微小分组数目，降低拥塞出现的可能（局域网这些小分组通常不会引起麻烦，但在较慢的广域网则存在拥塞的可能）。但相应的，因为不是立即ACK，也会增加更多的时延。
有时我们也需要关闭Nagle算法，例如鼠标移动必须无时延地发送，以便为用户的交互提供实时的反馈。

流程:
(1)发送端TCP将从应用进程接收到的第一数据块立即发送，不管其大小，哪怕只有一个字节。
(2)发送端输出第一块数据后开始收集数据，并等待确认。
(3)确认未达到时，若收集数据达到窗口的一半或一个MSS段，立即发送。
(4)确认到达后，把缓冲区中的数据组成一个TCP段，然后发送。

4、TCP的成块数据流

http://www.cnblogs.com/woaiyy/p/3554182.html

TCP管理4种不同的定时器：
重传定时器：当希望收到另一端的确认时使用。
坚持定时器：使窗口信息保持不断流动，即使另一端关闭了其接收窗口。
保活定时器：检测一个空闲连接的另一端何时崩溃或重启。
2MSL定时器：测量一个连接处于TIME_WATI状态的时间。

指数退避：书中检查连续重传之间不同的时间差，它们取整后分别是1、3、6、12、24、48和多个64秒，其中第一次发送后设置的超时时间设置为1.5秒。（2的N次方*1.5秒）

4.1 滑动窗口

滑动窗口协议
关于这部分自己不晓得怎么叙述才好，因为理解的部分更多，下面就用自己的理解来介绍下TCP的精髓：滑动窗口协议。
所谓滑动窗口协议，自己理解有两点：1. “窗口”对应的是一段可以被发送者发送的字节序列，其连续的范围称之为“窗口”；2. “滑动”则是指这段“允许发送的范围”是可以随着发送的过程而变化的，方式就是按顺序“滑动”。在引入一个例子来说这个协议之前，我觉得很有必要先了解以下前提：

1. TCP协议的两端分别为发送者A和接收者B，由于是全双工协议，因此A和B应该分别维护着一个独立的发送缓冲区和接收缓冲区，由于对等性（A发B收和B发A收），我们以A发送B接收的情况作为例子；
2. 发送窗口是发送缓存中的一部分，是可以被TCP协议发送的那部分，其实应用层需要发送的所有数据都被放进了发送者的发送缓冲区；
3. 发送窗口中相关的有四个概念：已发送并收到确认的数据（不再发送窗口和发送缓冲区之内）、已发送但未收到确认的数据（位于发送窗口之中）、允许发送但尚未发送的数据以及发送窗口外发送缓冲区内暂时不允许发送的数据；
4. 每次成功发送数据之后，发送窗口就会在发送缓冲区中按顺序移动，将新的数据包含到窗口中准备发送；

4.2 慢启动

1. 发送方维持一个叫做“拥塞窗口”的变量，该变量和接收端口共同决定了发送者的发送窗口；
2. 当主机开始发送数据时，避免一下子将大量字节注入到网络，造成或者增加拥塞，选择发送一个1字节的试探报文；
3. 当收到第一个字节的数据的确认后，就发送2个字节的报文；
4. 若再次收到2个字节的确认，则发送4个字节，依次递增2的指数级；
5. 最后会达到一个提前预设的“慢开始门限”，比如24，即一次发送了24个分组，此时遵循下面的条件判定：
   *1. cwnd < ssthresh， 继续使用慢开始算法；
   *2. cwnd > ssthresh，停止使用慢开始算法，改用拥塞避免算法；
   *3. cwnd = ssthresh，既可以使用慢开始算法，也可以使用拥塞避免算法；
6. 所谓拥塞避免算法就是：每经过一个往返时间RTT就把发送方的拥塞窗口+1，即让拥塞窗口缓慢地增大，按照线性规律增长；
7. 当出现网络拥塞，比如丢包时，将慢开始门限设为原先的一半，然后将cwnd设为1，执行慢开始算法（较低的起点，指数级增长）；

4.3 超时重传

http://blog.csdn.net/nizhannizhan/article/details/47688439
在请求包发出去的时候，开启一个计时器，当计时器达到时间之后，没有收到ACK，则就进行重发请求的操作，一直重发直到达到重发上限次数或者收到ACK。

4.4 快重传、快恢复

快重传：
1. 接收方建立这样的机制，如果一个包丢失，则对后续的包继续发送针对该包的重传请求；
2. 一旦发送方接收到三个一样的确认，就知道该包之后出现了错误，立刻重传该包；
3. 此时发送方开始执行“快恢复”算法

快恢复：
1. 慢开始门限减半；
2. cwnd设为慢开始门限减半后的数值；
3. 执行拥塞避免算法（高起点，线性增长）

5、坚持定时器

5.1 坚持定时器

是使用在一方滑动窗口为0之后，另外一方停止传输数据，进入坚持定时器的轮询，直到滑动窗口不再为0了。

5.2 糊涂窗口综合症。

这个症状是滑动窗口引起的。病因是发送方和接收方在一个很小的滑动窗口的时候就开始数据传输，传输结束之后，读写的消费速度也并没有那么快，导致下次传输的时候，滑动窗口还是那么小。然后现象就是每次传输的数据都非常小。就好比每次开出去的火车载货量只有一节车厢，其实我们是希望能攒够n节车厢才开始传输。

糊涂窗口综合症有解决办法，还不止一种，在接收方或者发送方都可以解决。大致就是如果接收方解决，那么接收方在接收窗口小于一定大小的时候，对所有的接收请求都返回窗口为0的包，来触发另外一方的坚持定时器。同样发送方也是，在可以发送的数据大于一定窗口的时候才发送。

6 TCP保活定时器

这个就是我们经常说的tcp的keepalive了。实际使用场景是在应用层没有数据进行传输的时候，一定时间（tcp_keepalive_time，默认每2个小时）发送一次保持心跳的包，如果发送成功，则继续保持端口活跃，如果没有正常返回，则在指定次数内（tcp_keepalive_probes，默认是9次），指定间隔（tcp_keepalive_intvl，默认是17s）发送心跳包。如果最后都没有获得正常的ACK，那么才算连接失败。

当然，tcp是否需要提供keepalive机制，是有争议的，我们可以为每个tcp连接设置是否启用keepalive和启用keepalive的各个指标设置。