TCP三次握手 四次挥手

TCP全称为Transmission Control Protocol（传输控制协议），是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。

TCP报文段结构

TCP协议的设计就是为了能够在客户端和服务器之间建立起一个可靠的连接，TCP是面向连接的，并且是可靠的

下图是TCP的报文段机构，通过这个结构来了解TCP提供的信息：

这里有几点是需要注意的：

• TCP 协议需要一个四元组（源IP，源端口，目的IP，目的端口）来确定连接，这要和 UDP 协议区分开。多说一句，IP 地址位于 IP 报文段，TCP 报文段是不含 IP 地址信息的。
• 基本 TCP 头部的长度是 20 字节，但是由于选项的长度是不确定的，所以需要首部长度字段明确给出头部长度。这里要注意的是，首部长度字段的单位是 32bit，也就是 4 字节，所以该字段的最小值是 5。
• 标橙色的字段（确认序号，接收窗口大小，ECE，ACK）用于回复对方，举个例子，服务器收到对方的数据包后，不单独发一个数据包来回应，而是稍微等一下，把确认信息附在下一个发往客户端的数据帧上，也就是捎带技术。
• 窗口大小是一个 16 位无符号数，也就是说窗口被限制在了 65535 字节，也就限制了 TCP 的吞吐量性能，这对一些高速以及高延迟的网络不太友好（可以想想为什么）。所幸 TCP 额外提供了窗口缩放（Window Scale）选项，允许对这个值进行缩放。

下面是 8 个标志位的含义，有的协议比较旧，可能没有前两个标志位：

标志位虽然很多，但是如果放到具体场景里来看的话，就很容易理解他们的作用了。

TCP三次握手

TCP运输连接有三个阶段：连接建立、数据传送、连接释放
TCP连接过程通常叫做握手，握手需要客户端和服务器端交换三个报文，如下图所示
之所以需要三次握手是因为TCP是可靠传输，三次能够刚好可靠又不多余
客户端有CLOSED、SYN-SEND、ESTABLISHED三种状态
服务端有CLOSED、LISTEN、SYN-RCVD、ESTABLISHED四种状态
服务器会首先创建连接，并且进入监听等待阶段，等待客户端的请求
当需要发送请求时，浏览器客户端主动打开连接，然后服务器被动打开连接

连接过程

三次握手：服务端新建套接字，绑定地址信息后开始监听，进入LISTEN状态。客户端新建套接字绑定地址信息后调用connect，发送连接请求SYN，并进入SYN_SENT状态，等待服务器的确认。服务端一旦监听到连接请求，就会将连接放入内核等待队列中，并向客户端发送SYN和确认报文段ACK，进入SYN_RECD状态。客户端收到SYN+ACK报文后向服务端发送确认报文段ACK，并进入ESTABLISHED状态，开始读写数据。服务端一旦收到客户端的确认报文，就进入ESTABLISHED状态，就可以进行读写数据了

第一次握手

首先是客户端发起连接，第一个数据包将 SYN 置位（也就是 SYN = 1），表明这个数据包是 SYN 报文段（也被称为段 1）。这一次发送的目的是告诉服务器，自己的初始序列号是 client_isn ，还有一个隐含的信息在图里没有表现出来，那就是告知服务端自己想连接的端口号。

除了这些，客户端还会发送一些选项，不过这跟三次握手没多大关系

段 1 里最需要注意的就是这个client_isn ，也就是初始序列号。「RFC0793^1」指出:

When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN. The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented roughly every 4 microseconds. Thus, the ISN cycles approximately every 4.55 hours.

翻译过来就是，初始序列号是一个 32 位的（虚拟）计数器，而且这个计数器每 4 微秒加 1，也就是说，ISN 的值每 4.55 小时循环一次。这个举措是为了防止序列号重叠。

但即使这样还是会有安全隐患——因为初始 ISN 仍然是可预测的，恶意程序可能会分析 ISN ，然后根据先前使用的 ISN 预测后续 TCP 连接的 ISN，然后进行攻击，一个著名的例子就是「The Mitnick attack^2」 。这里摘一段原文：

Mitnick sent SYN request to X-Terminal and received SYN/ACK response. Then he sent RESET response to keep the X-Terminal from being filled up. He repeated this for twenty times. He found there is a pattern between two successive TCP sequence numbers. It turned out that the numbers were not random at all. The latter number was greater than the previous one by 128000.

所以为了让初始序列号更难预测，现代系统常常使用半随机的方法选择初始序列号，详细的方法就不在这里展开了。

第二次握手

当服务器接收到客户端的连接请求后，就会向客户端发送 ACK 表示自己收到了连接请求，而且，服务器还得把自己的初始序列号告诉客户端，这其实是两个步骤，但是发送一个数据包就可以完成，用的就是前面说的捎带技术。图里的 ACK = client_isn + 1 是指确认号字段的值，要注意和 ACK 标志位区分开。

ACK 字段其实也有不少需要注意的点，不过这个跟滑动窗口一块讲比较直观，这里就先不提了。

这里重点强调一下，当一个 SYN 报文段到达的时候，服务器会检查处于 SYN_RCVD 状态的连接数目是否超过了 tcp_max_syn_backlog 这个参数，如果超过了，服务器就会拒绝连接。当然，这个也会被黑客所利用，「SYN Flood」就是个很好的例子。因为服务器在回复 SYN-ACK 后，会等待客户端的 ACK ，如果一定时间内没有收到，认为是丢包了，就重发 SYN-ACK，重复几次后才会断开这个连接，linux 可能要一分钟才会断开，所以攻击者如果制造一大批 SYN 请求而不回复，服务器的 SYN 队列很快就被耗尽，这一段时间里，正常的连接也会得不到响应。

服务器的这种状态称为静默（muted）。为了抵御 SYN Flood 攻击，服务器可以采用「SYN cookies」，这种思想是，当 SYN 到达时，并不直接为其分配内存，而是把这条连接的信息编码并保存在 SYN-ACK 报文段的序列号字段，如果客户端回复了，服务器再从 ACK 字段里解算出 SYN 报文的重要信息（有点黑魔法的感觉了），验证成功后才为该连接分配内存。这样，服务器不会响应攻击者的请求，正常连接则不会受到影响。

但 SYN cookies 本身有一些限制，并不适合作为默认选项，有兴趣可以自行 Google。

第三次握手

这是建立 TCP 连接的最后一步，经过前两次握手，客户端（服务器）已经知道对方的滑动窗口大小，初始序列号等信息了，这不就完了吗？为什么还要第三次握手？

这是因为服务器虽然把数据包发出去了，但他还不知道客户端是否收到了这个包，所以服务器需要等待客户端返回一个 ACK，表明客户端收到了数据，至此，连接完成

总体概念：
客户端：发出确认请求，SYN=1，seq=x，你听得到么，我想建立连接（SYN=1），我的序号是x（seq=x）
服务器：对请求进行确认，也就是回应，我听到了（ACK=1，ack=x+1），你听得到么（SYN=1），我的序号是y（seq=y）
客户端：对服务器的回应进行确认，我听到了（ACK=1，ack=y+1），我的序号是x+1

IP数据报经过运输层需要分段发送，所以在TCP的处理过程中，有序号的概念
比如客户端说我要从666号开始，发送100个数据，服务器说，我是从888号开始回应的
上面的seq=x 和 seq=y seq=x+1（上一个seq=x，下一个自然就是seq=x+1了）都是各自的序号
握手的过程就是SYN seq ACK ack的来回确认
SYN ACK是头部的字段，可以理解为标志位，协议中有对他们的值有具体的规定
ack就是确认号，确认号是期望收到的对方的下一个报文段的第一个数据字节的序号，也就是收到的序号+1
否则随便一个，怎么对得上号

为什么要三次握手？而不是两次或者四次？

两次不安全，四次没必要。tcp通信需要确保双方都具有数据收发的能力，得到ACK响应则认为对方具有数据收发的能力，因此双方都要发送SYN确保对方具有通信的能力。第一次握手是客户端发送SYN，服务端接收，服务端得出客户端的发送能力和服务端的接收能力都正常；第二次握手是服务端发送SYN+ACK，客户端接收，客户端得出客户端发送接收能力正常，服务端发送接收能力也都正常，但是此时服务器并不能确认客户端的接收能力是否正常；第三次握手客户端发送ACK，服务器接收，服务端才能得出客户端发送接收能力正常，服务端自己发送接收能力也都正常

如果不是三次握手，只有两次
如果客户端发出请求连接时，报文延时了，于是客户端重新发送了一次连接请求消息
后来收到了确认，建立了连接，然后完成了数据传输，关闭了连接
此时，服务器收到了那个迟到的请求消息，此时他应该是个废物了
此时如果只有两次握手，服务器收到请求就响应建立了连接了
但是如果是三次，客户端不会再次确认，服务器也就随后知道了这消息有问题，不会建立连接

三次握手可以携带数据吗？

第一次、第二次握手不可以携带数据，而第三次握手是可以携带数据的。假设第一次可以携带数据，如果有人恶意攻击服务器，每次都在第一次握手中的SYN报文放入大量数据，重复发送大量SYN报文，此时服务器会花费大量内存空间来缓冲这些报文，服务器就更容易被攻击了

tcp三次握手失败，服务端会如何处理?

握手失败的原因有两种，第一种是服务端没有收到SYN，则什么都不做；第二种是服务端回复了SYN+ACK后，长时间没有收到ACK响应，则超时后就会发送RST重置连接报文，释放资源

ISN代表什么？意义何在？ISN是固定不变的吗？ISN为何要动态随机

ISN全称是Initial Sequence Number，是TCP发送方的字节数据编号的原点，告诉对方我要开始发送数据的初始化序列号。ISN如果是固定的，攻击者很容易猜出后序的确认号，为了安全起见，避免被第三方猜到从而发送伪造的RST报文，因此ISN是动态生成的

什么是半连接队列

服务器第一次收到客户端的SYN之后，就会处于SYN_RECD状态，此时双方还没有完全建立连接。服务器会把这种状态下的请求连接放在一个队列里，我们把这种队列称之为半连接队列。当然还有一个全连接队列，就是已经完成三次握手，建立起来连接的就会放在全连接队列中，如果队列满了就有可能出现丢包现象

SYN攻击：

属于DOS攻击的一种，利用TCP协议，通过发送大量的半连接请求，耗费CP和内存资源。SYN攻击除了能影响主机外，还可以危害路由器、防火墙等网络系统，事实上SYN攻击并不管目标是什么系统，只要这些系统打开TCP服务就可以实施。互联网有大量现成的SYN攻击工具

检测SYN攻击：检测SYN攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。我们使用系统自带的netstat 工具来检测SYN攻击：
#netstat -n -p TCP
#netstat -n -p TCP 　 GREP SYN_RECV 查询该状态的数量

SYN攻击防范技术: 参考

TCP四次挥手

四次挥手：客户端主动调用close时，向服务端发送结束报文段FIN报，同时进入FIN_WAIT1状态；服务器会收到结束报文段FIN报，服务器返回确认报文段ACK并进入CLOSE_WAIT状态，此时如果服务端有数据要发送的话，客户端依然需要接收。客户端收到服务器对结束报文段的确认，就会进入到FIN_WAIT2状态，开始等待服务器的结束报文段；服务器端数据发送完毕后，当服务器真正调用close关闭连接时，会向客户端发送结束报文段FIN包，此时服务器进入LAST_ACK状态，等待最后一个ACK的带来；客户端收到服务器发来的结束报文段, 进入TIME_WAIT, 并发出送确认报文段ACK；服务器收到了对结束报文段确认的ACK，进入CLOSED状态，断开连接。而客户端要等待2MSL的时间，才会进入到CLOSED状态

为什么握手是三次，而挥手时需要四次呢？

其实在TCP握手的时候，接收端将SYN包和ACK确认包合并到一个包中发送的，所以减少了一次包的发送。对于四次挥手，由于TCP是全双工通信，主动关闭方发送FIN请求不代表完全断开连接，只能表示主动关闭方不再发送数据了。而接收方可能还要发送数据，就不能立即关闭服务器端到客户端的数据通道，所以就不能将服务端的FIN包和对客户端的ACK包合并发送，只能先确认ACK，等服务器无需发送数据时在发送FIN包，所以四次挥手时需要四次数据包的交互

TIME_WAIT状态有什么作用，为什么主动关闭方没有直接进入CLOSED状态释放资源？

如果主动关闭方进入CLOSED状态后，被动关闭方发送FIN包后没有得到ACK确认，超时后就会重传一个FIN包。如果客户端没有TIME_WAIT状态而直接进入CLOSED状态释放资源，下次启动新的客户端就可能使用了与之前客户端相同的地址信息

有两个危害: 第一种是这个刚启动的新的客户端绑定地址成功时，就会收到了一个重传的FIN包，对新连接就会造成影响。第二种是如果该新客户端向相同的服务端发送SYN连接请求，但是此时服务端处于LAST_ACK状态，要求收到的是ACK而不是SYN，因此就会发送RST重新建立请求

为什么TIME_WAIT状态需要经过2MSL才能进入CLOASE状态?

MSL指的是报文在网络中最大生存时间。在客户端发送对服务端的FIN确认包ACK后，这个ACK包有可能到达不了，服务器端如果接收不到ACK包就会重新发送FIN包。所以客户端发送ACK后需要留出2MSL时间（ACK到达服务器器+服务器发送FIN重传包，一来一回）等待确认服务器端确实收到了ACK包。也就是说客户端如果等待2MSL时间也没收到服务器端重传的FIN包，则就可以确认服务器已经收到客户端发送的ACK包

一台主机上出现大量的TIME_WAIT是什么原因？应该如何处理？

CLOSE_WAIT是被动关闭方收到FIN请求进行回复之后的状态，等待上层程序进一步处理，若出现大量CLOSE_WAIT，有可能是被动关闭方主机程序中忘了最后一步断开连接后调用close释放资源。这是一个 BUG，只需要加上对应的 close 即可解决问题

tcp连接管理中的保活机制

tcp通信中，若两端长时间没有数据往来，则这时候每隔一段时间，服务端会向客户端发送一个保活探测数据报，要求客户端进行回复。若连续多次没有收到响应，就认为连接已经断开。长时间默认为7200s，每隔一段时间默认为75s，连续多次无响应默认为9次。这些数据都可以在套接字中修改，接口：Setsockopt

TIME_WAIT状态

四次挥手里值得关注的一点就是 TIME_WAIT 状态，也就是说主动关闭连接的一方，即使收到了对方的 FIN 报文，也还要等待 2MSL 的时间才会彻底关闭这条连接。（这里面的 MSL 指的是最大段生存期，指的是报文段在网络中被允许存在的最长时间。）可为什么不直接关闭连接呢？

一个原因是，第四次挥手的 ACK 报文段不一定到达了服务器，为了不让服务器一直处于 LAST_ACK 状态（服务器会重发 FIN，直到收到 ACK），客户端还得等一会儿，看看是否需要重发。假如真的丢包了，服务器发送 FIN ，这个 FIN 报文到达客户端时不会超过 2MSL（一来一回最多 2MSL），这时候客户端这边的 TCP 还没关掉，还能重发 ACK。

另一个原因是，经过 2MSL 之后，网络中与该连接相关的包都已经消失了，不会干扰新连接。我们来看一个例子：假如客户端向服务器建立了新的连接，旧连接中某些延迟的数据坚持到了新连接建立完毕，而且序列号刚好还在滑动窗口内，服务器就误把它当成新连接的数据包接收，如下图所示：

2MSL 机制就避免了这种情况。