tcp ，基础概念 三次握手，4次挥手

一。为何建连接要3次握手，断连接须要4次挥手？

• 对于建连接的3次握手：主要是要初始化Sequence Number 的初始值。通讯的双方要互相通知对方本身的初始化的Sequence Number（缩写为ISN：Inital Sequence Number）——因此叫SYN，全称Synchronize Sequence Numbers。也就上图中的 x 和 y。这个号要做为之后的数据通讯的序号，以保证应用层接收到的数据不会由于网络上的传输的问题而乱序（TCP会用这个序号来拼接数据）。
• 对于4次挥手：其实你仔细看是2次，由于TCP是全双工的，因此，发送方和接收方都须要Fin和Ack。只不过，有一方是被动的，因此看上去就成了所谓的4次挥手。若是两边同时断链接，那就会就进入到CLOSING状态，而后到达TIME_WAIT状态。

二。服务器保持了大量TIME_WAIT状态

这种状况比较常见，一些爬虫服务器或者WEB服务器（若是网管在安装的时候没有作内核参数优化的话）上常常会遇到这个问题，这个问题是怎么产生的呢？

从 上面的示意图能够看得出来，TIME_WAIT是主动关闭链接的一方保持的状态，对于爬虫服务器来讲他自己就是“客户端”，在完成一个爬取任务以后，他就 会发起主动关闭链接，从而进入TIME_WAIT的状态，而后在保持这个状态2MSL（max segment lifetime）时间以后，完全关闭回收资源。为何要这么作？明明就已经主动关闭链接了为啥还要保持资源一段时间呢？这个是TCP/IP的设计者规定 的，主要出于如下两个方面的考虑：

1.防止上一次链接中的包，迷路后从新出现，影响新链接（通过2MSL，上一次链接中全部的重复包都会消失）
2. 可靠的关闭TCP链接。在主动关闭方发送的最后一个 ack(fin) ，有可能丢失，这时被动方会从新发fin, 若是这时主动方处于 CLOSED 状态 ，就会响应 rst 而不是 ack。因此主动方要处于 TIME_WAIT 状态，而不能是 CLOSED 。另外这么设计TIME_WAIT 会定时的回收资源，并不会占用很大资源的，除非短期内接受大量请求或者受到攻击。

三、经过上面的ISN的描述，相信你也知道MSL是怎么来的了。咱们注意到，在TCP的状态图中，从TIME_WAIT状态到CLOSED状态，有一个超时设置，这个超时设置是 2*MSL（RFC793定义了MSL为2分钟，Linux设置成了30s）为何要这有TIME_WAIT？为何不直接给转成CLOSED状态呢？主要有两个缘由：1）TIME_WAIT确保有足够的时间让对端收到了ACK，若是被动关闭的那方没有收到Ack，就会触发被动端重发Fin，一来一去正好2个MSL，2）有足够的时间让这个链接不会跟后面的链接混在一块儿（你要知道，有些自作主张的路由器会缓存IP数据包，若是链接被重用了，那么这些延迟收到的包就有可能会跟新链接混在一块儿）。你能够看看这篇文章《TIME_WAIT and its design implications for protocols and scalable client server systems》

三。TCP重传机制

TCP要保证全部的数据包均可以到达，因此，必须要有重传机制。

注意：接收端给发送端的Ack确认只会确认最后一个连续的包，好比，发送端发了1,2,3,4,5一共五份数据，接收端收到了1，2，因而回ack 3，而后收到了4（注意此时3没收到），此时的TCP会怎么办？咱们要知道，由于正如前面所说的，SeqNum和Ack是以字节数为单位，因此ack的时候，不能跳着确认，只能确认最大的连续收到的包，否则，发送端就觉得以前的都收到了。

四。快速重传机制

因而，TCP引入了一种叫Fast Retransmit 的算法，不以时间驱动，而以数据驱动重传。也就是说，若是，包没有连续到达，就ack最后那个可能被丢了的包，若是发送方连续收到3次相同的ack，就重传。Fast Retransmit的好处是不用等timeout了再重传。

好比：若是发送方发出了1，2，3，4，5份数据，第一份先到送了，因而就ack回2，结果2由于某些缘由没收到，3到达了，因而仍是ack回2，后面的4和5都到了，可是仍是ack回2，由于2仍是没有收到，因而发送端收到了三个ack=2的确认，知道了2尚未到，因而就立刻重转2。而后，接收端收到了2，此时由于3，4，5都收到了，因而ack回6。

五。D-SACK，有这么几个好处：
 

• 1）可让发送方知道，是发出去的包丢了，仍是回来的ACK包丢了。
• 2）是否是本身的timeout过小了，致使重传。
• 3）网络上出现了先发的包后到的状况（又称reordering）
• 4）网络上是否是把个人数据包给复制了。

知道这些东西能够很好得帮助TCP了解网络状况，从而能够更好的作网络上的流控。Linux下的tcp_dsack参数用于开启这个功能（Linux 2.4后默认打开）

 

1：滑动窗口

2：流量控制
3：拥塞控制
4：Nagle算法
5：捎带ACK的发送方式
这个策略是说，当主机收到远程主机的TCP数据报以后，一般不立刻发送ACK数据报，而是等上一个短暂的时间，若是这段时间里面主机还有发送到远程主机的TCP数据报，那么就把这个ACK数据报“捎带”着发送出去，把原本两个TCP数据报整合成一个发送。通常的，这个时间是200ms。能够明显地看到这个策略能够把TCP数据报的利用率提升不少。

6.白痴综合征

滑窗机制有可能犯病，好比白痴窗口综合症（Silly Window Syndrome）。假设这样一种情形：接收方发布（advertise）一个小的窗口。发送方根据发布的窗口大小，发送一个小的片断。接收方的小窗口被填满，通过处理，接收方再宣布一个小的窗口…… 这就是“白痴窗口综合症”：TCP通讯的片断中包含的数据量很小。在这样的状况下，TCP通讯的片断所含的信息都很小，网络流量主要是TCP片断的头部，这样头重脚轻的TCP片断，会形成网络流量的浪费。
若是发送方不断发送小的片断，也会形成白痴窗口。为了解决这个问题，须要从两方面入手。TCP中有相关的规定，要求：

1》. 接收方宣告的窗口必须达到必定的尺寸，不然等待。
2》. 除了一些特殊状况，发送方发送的片断必须达到必定的尺寸，不然等待。特殊状况主要是指须要最小化延迟的TCP应用，好比命令行互动。

7. 重传

接收方（receiver）能够经过校验TCP片断头部中校验（checksum）区域来检验TCP片断是否出错。校验区域所在位置以下图所示。咱们已经接触过了IP协议详解的校验算法。TCP片断的校验算法与之相似。IP协议只校验头部，TCP片断头部的校验会校验包括IP头部、TCP头部和TCP数据在内的整个序列，确保IP地址、端口号和其余相关信息正确。若是TCP片断出错，接收方能够简单的丢弃改TCP片断，也就至关于TCP片断丢失。