目录
3.关于三次握手的连环发问(面试常问知识点)
专栏其他文章：
理论篇：
(二）深入浅出TCPIP之再识TCP，理解TCP三次握手（上）
(三）深入浅出TCPIP之再识TCP，理解TCP四次挥手（上）
(四）深入浅出TCPIP之TCP三次握手和四次挥手（下）的抓包分析
(七）深入浅出TCPIP之深入浅出TCPIP之TCP重传机制
(十四）深入浅出TCPIP之初识UDP理解报文格式和交互流程
....
实践篇：
深入浅出TCPIP之实战篇—用c++开发一个http服务器（二十一）
其他网络编程实践篇+游戏网络疑难杂症解读 文章正在更新中。。。
TCP作为一种可靠传输控制协议，其核心思想：既要保证数据可靠传输，又要提高传输的效率，而用三次握手恰恰可以满足以上两方面的需求！
1.三次握手
所谓的三次握手即TCP连接的建立。这个连接必须是一方主动打开，另一方被动打开的。TCP协议中，我们把主动发起请求的一端称为『客户端』，被动连接的一端称为『服务端』。不管是客户端还是服务端，TCP连接建立完后都能发送和接收数据。
1.1 三次握手过程
握手之前主动打开连接的客户端结束CLOSED阶段，被动打开的服务器端也结束CLOSED阶段，并进入LISTEN阶段。随后开始“三次握手”：
第一次握手
客户端向服务端发送连接请求报文段。该报文段的头部中SYN=1，ACK=0，seq=x。请求发送后，客户端便进入SYN-SENT状态。
- PS1：SYN=1，ACK=0表示该报文段为连接请求报文。
- PS2：x为本次TCP通信的字节流的初始序号。
TCP规定：SYN=1的报文段不能有数据部分，但要消耗掉一个序号。
第二次握手
服务端收到连接请求报文段后，如果同意连接，则会发送一个应答：SYN=1，ACK=1，seq=y，ack=x+1。
该应答发送完成后便进入SYN-RCVD状态。
- PS1：SYN=1，ACK=1表示该报文段为连接同意的应答报文。
- PS2：seq=y表示服务端作为发送者时，发送字节流的初始序号。
- PS3：ack=x+1表示服务端希望下一个数据报发送序号从x+1开始的字节。
第三次握手
当客户端收到连接同意的应答后，还要向服务端发送一个确认报文段，表示：服务端发来的连接同意应答已经成功收到。
该报文段的头部为：ACK=1，seq=x+1，ack=y+1。
客户端发完这个报文段后便进入ESTABLISHED状态，服务端收到这个应答后也进入ESTABLISHED状态，此时连接的建立完成！
在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性。一旦出现某一方发出的TCP报文丢失，便无法继续"握手"，以此确保了"三次握手"的顺利完成。
例如：
一句话概括，TCP连接握手握的是啥?
通信双方数据原点的序列号！
1.2 TCP连接状态
CLOSED：没有任何连接状态；
LISTENING：侦听来自远方的TCP端口的连接请求；
首先服务端需要打开一个socket进行监听，状态为LISTEN。
有提供某种服务才会处于LISTENING状态，TCP状态变化就是某个端口的状态变化，提供一个服务就打开一个端口，例如：提供www服务默认开的是80端口，提供ftp服务默认的端口为21，当提供的服务没有被连接时就处于LISTENING状态。FTP服务启动后首先处于侦听（LISTENING）状态。处于侦听LISTENING状态时，该端口是开放的，等待连接，但还没有被连接。就像你房子的门已经敞开的，但还没有人进来。
看LISTENING状态最主要的是看本机开了哪些端口，这些端口都是哪个程序开的，关闭不必要的端口是保证安全的一个非常重要的方面，服务端口都对应一个服务（应用程序），停止该服务就关闭了该端口，例如要关闭21端口只要停止IIS服务中的FTP服务即可。关于这方面的知识请参阅其它文章。
如果你不幸中了服务端口的木马，木马也开个端口处于LISTENING状态。
SYN-SENT：客户端SYN_SENT状态：
再发送连接请求后等待匹配的连接请求:客户端通过应用程序调用connect进行active open.于是客户端tcp发送一个SYN以请求建立一个连接.之后状态置为SYN_SENT. 在发送连接请求后等待匹配的连接请求
当请求连接时客户端首先要发送同步信号给要访问的机器，此时状态为SYN_SENT，如果连接成功了就变为ESTABLISHED，正常情况下SYN_SENT状态非常短暂。例如要访问网站http://www.baidu.com,如果是正常连接的话，用TCPView观察IE建立的连接会发现很快从SYN_SENT变为ESTABLISHED，表示连接成功。SYN_SENT状态快的也许看不到。
如果发现有很多SYN_SENT出现，那一般有这么几种情况，一是你要访问的网站不存在或线路不好，二是用扫描软件扫描一个网段的机器，也会出出现很多SYN_SENT，另外就是可能中了病毒了，例如中了"冲击波"，病毒发作时会扫描其它机器，这样会有很多SYN_SENT出现。
SYN-RECEIVED：服务器端状态SYN_RCVD
再收到和发送一个连接请求后等待对方对连接请求的确认
当服务器收到客户端发送的同步信号时，将标志位ACK和SYN置1发送给客户端，此时服务器端处于SYN_RCVD状态，如果连接成功了就变为ESTABLISHED，正常情况下SYN_RCVD状态非常短暂。
如果发现有很多SYN_RCVD状态，那你的机器有可能被SYN Flood的DoS(拒绝服务攻击)攻击了。
ESTABLISHED：代表一个打开的连接。
ESTABLISHED状态是表示两台机器正在传输数据，观察这个状态最主要的就是看哪个程序正在处于ESTABLISHED状态。
服务器出现很多ESTABLISHED状态： netstat -nat |grep 9502或者使用lsof -i:9502可以检测到。
当客户端未主动close的时候就断开连接：即客户端发送的FIN丢失或未发送。
这时候若客户端断开的时候发送了FIN包，则服务端将会处于CLOSE_WAIT状态；
这时候若客户端断开的时候未发送FIN包，则服务端处还是显示ESTABLISHED状态；
结果客户端重新连接服务器。
而新连接上来的客户端（也就是刚才断掉的重新连上来了）在服务端肯定是ESTABLISHED; 如果客户端重复的上演这种情况，那么服务端将会出现大量的假的ESTABLISHED连接和CLOSE_WAIT连接。
最终结果就是新的其他客户端无法连接上来，但是利用netstat还是能看到一条连接已经建立，并显示ESTABLISHED，但始终无法进入程序代码
FIN-WAIT-1：等待远程TCP连接中断请求，或先前的连接中断请求的确认
主动关闭(active close)端应用程序调用close，于是其TCP发出FIN请求主动关闭连接，之后进入FIN_WAIT1状态./* The socket is closed, and the connection is shutting down. 等待远程TCP的连接中断请求，或先前的连接中断请求的确认 */
如果服务器出现shutdown再重启，使用netstat -nat查看，就会看到很多FIN-WAIT-1的状态。就是因为服务器当前有很多客户端连接，直接关闭服务器后，无法接收到客户端的ACK。
FIN-WAIT-2：从远程TCP等待连接中断请求
主动关闭端接到ACK后，就进入了FIN-WAIT-2，从远程TCP等待连接中断请求
这就是著名的半关闭的状态了，这是在关闭连接时，客户端和服务器两次握手之后的状态。在这个状态下，应用程序还有接受数据的能力，但是已经无法发送数据，但是也有一种可能是，客户端一直处于FIN_WAIT_2状态，而服务器则一直处于WAIT_CLOSE状态，而直到应用层来决定关闭这个状态。
CLOSE-WAIT：等待从本地用户发来的连接中断请求
被动关闭(passive close)端TCP接到FIN后，就发出ACK以回应FIN请求(它的接收也作为文件结束符传递给上层应用程序),并进入CLOSE_WAIT.等待从本地用户发来的连接中断请求
CLOSING：等待远程TCP对连接中断的确认
等待远程TCP对连接中断的确认
LAST-ACK：等待原来的发向远程TCP的连接中断请求的确认
被动关闭端一段时间后，接收到文件结束符的应用程序将调用CLOSE关闭连接。这导致它的TCP也发送一个 FIN,等待对方的ACK.就进入了LAST-ACK 等待原来发向远程TCP的连接中断请求的确认
使用并发压力测试的时候，突然断开压力测试客户端，服务器会看到很多LAST-ACK。
TIME-WAIT：等待足够的时间以确保远程TCP接收到连接中断请求的确认
在主动关闭端接收到FIN后，TCP就发送ACK包，并进入TIME-WAIT状态，等待足够的时间以确保远程TCP接收到连接中断请求的确认 */
TIME_WAIT等待状态，这个状态又叫做2MSL状态，说的是在TIME_WAIT2发送了最后一个ACK数据报以后，要进入TIME_WAIT状态，这个状态是防止最后一次握手的数据报没有传送到对方那里而准备的（注意这不是四次握手，这是第四次握手的保险状态）。这个状态在很大程度上保证了双方都可以正常结束，但是，问题也来了。由于插口的2MSL状态（插口是IP和端口对的意思，socket），使得应用程序在2MSL时间内是无法再次使用同一个插口的，对于客户程序还好一些，但是对于服务程序，例如httpd，它总是要使用同一个端口来进行服务，而在2MSL时间内，启动httpd就会出现错误（插口被使用）。为了避免这个错误，服务器给出了一个平静时间的概念，这是说在2MSL时间内，虽然可以重新启动服务器，但是这个服务器还是要平静的等待2MSL时间的过去才能进行下一次连接。
1.3 TCP状态迁移路线分析
client/server两条路线讲述TCP状态迁移路线图：
这是一个看起来比较复杂的状态迁移图，因为它包含了两个部分—-服务器的状态迁移和客户端的状态迁移，如果从某一个角度出发来看这个图，就会清晰许多，这里面的服务器和客户端都不是绝对的，发送数据的就是客户端，接受数据的就是服务器。
客户端应用程序的状态迁移图
客户端的状态可以用如下的流程来表示：
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
以上流程是在程序正常的情况下应该有的流程，从书中的图中可以看到，在建立连接时，当客户端收到SYN报文的ACK以后，客户端就打开了数据交互地连接。
而结束连接则通常是客户端主动结束的，客户端结束应用程序以后，需要经历FIN_WAIT_1，FIN_WAIT_2等状态，这些状态的迁移就是前面提到的结束连接的四次握手。
服务器的状态迁移图
服务器的状态可以用如下的流程来表示：
CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED
在建立连接的时候，服务器端是在第三次握手之后才进入数据交互状态，而关闭连接则是在关闭连接的第二次握手以后（注意不是第四次）。而关闭以后还要等待客户端给出最后的ACK包才能进入初始的状态。
其他状态迁移
还有一些其他的状态迁移，这些状态迁移针对服务器和客户端两方面的总结如下
LISTEN->SYNSENT，对于这个解释就很简单了，服务器有时候也要打开连接的嘛。
SYN_SENT->SYN收到，服务器和客户端在SYN_SENT状态下如果收到SYN数据报，则都需要发送SYN的ACK数据报并把自己的状态调整到SYN收到状态，准备进入ESTABLISHED
SYN_SENT->CLOSED，在发送超时的情况下，会返回到CLOSED状态。
SYN收到->LISTEN，如果受到RST包，会返回到LISTEN状态。
SYN_收到->FIN_WAIT_1，这个迁移是说，可以不用到ESTABLISHED状态，而可以直接跳转到FIN_WAIT_1状态并等待关闭。
1.4 查看TCP状态命令
了解TCP状态之后了解几个linux查看tcp的状态命令：
1) netstat -nat查看TCP各个状态的数量
2)lsof -i:port可以检测到打开套接字的状况
3) sar -n SOCK查看tcp创建的连接数
4) tcpdump -iany tcp port 9000对tcp端口为9000的进行抓包
网络测试常用命令;
1）ping:检测网络连接的正常与否,主要是测试延时、抖动、丢包率。
但是很多服务器为了防止攻击，一般会关闭对ping的响应。所以ping一般作为测试连通性使用。
ping命令后，会接收到对方发送的回馈信息，其中记录着对方的IP地址和TTL。TTL是该字段指定IP包被路由器丢弃之前允许通过的最大网段数量。
TTL是IPv4包头的一个8 bit字段。例如IP包在服务器中发送前设置的TTL是64，你使用ping命令后，得到服务器反馈的信息，其中的TTL为56，说明途中一共经过了8道路由器的转发，每经过一个路由，TTL减1。
2）traceroute：raceroute 跟踪数据包到达网络主机所经过的路由工具
traceroute hostname
3）pathping：是一个路由跟踪工具，它将 ping 和 tracert 命令的功能与这两个工具所不提供的其他信息结合起来，综合了二者的功能
pathping www.baidu.com
4）mtr：以结合ping nslookup tracert 来判断网络的相关特性
5) nslookup:用于解析域名，一般用来检测本机的DNS设置是否配置正确
2. 二次握手和四次握手
根据三次握手的核心思想我们来分析二、四次握手的过程。
2.1 四次握手的过程:
1.发送同步信号SYN+A的初始序列号
2.B确认收到A的同步信号，并记录A‘s是到本地，命名B的ACK序列号
3.B发送同步信号SYN+B的初始序列号
4.A确认收到B的同步信号，并记录B‘s是到本地，命名A的ACK序列号
很显然2和3这两个步骤可以合并，只需要三次握手,可以提高连接的速度与效率。
2.2二次握手的过程:
1.A发送同步信号SYN+A的初始序列号
2.B发送同步信号SYN+B的初始序列号+B的ACK序号
这里有一个问题，A与B就A的初始序列号达成了一致.但是B无法知道A是否已经接收到自己的同步信号,如果这个同步信号丢失了, A和B就B的初始序列号将无法达成一致。
如图：
于是tcp的设计者将SYN这个同步标志位SYN设计成占用一个字节的编号(FIN标志位也是)，既然是一个字节的数据，按照tcp对有数据的tcp段必须确认的原则，所以在这里A必须给B一个确认，以确认A已经接收到B的同步信号。
有童鞋会说，如果A发给B的确认丢了，该如何?会超时重传这个ack吗？不会！Tcp不会为没有数据的ack超时重传.
那该如何是好？B如果没有收到A的ack，超时重传自己的syn同步号，直到收到A的ack为止。
3.关于三次握手的连环发问
1. 三次握手的第一个包，即A发给B的SYN中途被丢，没有到达B会怎么样？
A会周期性超时重传，直到收到B的确认
2.三次握手的第二个包，即B发给A的SYN+ACK中途被丢，没有到达A会怎么样？
B会周期性超时重传，直到收到A的确认
3.三次握手的第三个包，即A发给B的ACK中途被丢，没有到达B会怎么样？
A发完ACK,单方面认为TCP为Established状态，而B显然认为TCP为Active状态:
a.假定此时双方都没有数据发送，B会周期性超时重传，直到收到A的确认，收到之后B的TCP连接也为Established状态，双向可以发包。
b.假定此时A有数据发送，B收到A的Data + ACK，自然会切换为established 状态，并接受A的数据。
c.假定B有数据发送，数据发送不了，会一直周期性超时重传SYN+ACK，直到收到A的确认才可以发送数据.
4.为什么连接建立需要三次握手，而不是两次握手？
防止失效的连接请求报文段被服务端接收，从而产生错误。
PS：失效的连接请求：若客户端向服务端发送的连接请求丢失，客户端等待应答超时后就会再次发送连接请求，此时，上一个连接请求就是『失效的』。
若建立连接只需两次握手，客户端并没有太大的变化，仍然需要获得服务端的应答后才进入ESTABLISHED状态，而服务端在收到连接请求后就进入ESTABLISHED状态。此时如果网络拥塞，客户端发送的连接请求迟迟到不了服务端，客户端便超时重发请求，如果服务端正确接收并确认应答，双方便开始通信，通信结束后释放连接。此时，如果那个失效的连接请求抵达了服务端，由于只有两次握手，服务端收到请求就会进入ESTABLISHED状态，等待发送数据或主动发送数据。但此时的客户端早已进入CLOSED状态，服务端将会一直等待下去，这样浪费服务端连接资源。
5.如果已经建立了连接，但是客户端突然出现故障了怎么办？(网络CLOSE)
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
转载：https://blog.csdn.net/pbymw8iwm/article/details/109382880