三次握手（建立连接）
（1）序号：seq序号，占32位，用来标识从TCP客户端向目的端发送的字节流，发起方发送数据时对此进行标记。
（2）确认序号：ack序号，占32位，这个序号和发起的序号有关，在接受到信号后，将ACK置为1，才可以产生ack，且当ACK为1时，ack确认序号才有效，ack=seq+1。
（3）标志位：
SYN：发起一个新连接。
ACK：确认序号有效。
FIN： 释放一个连接。
PSH：接受方应该尽快将这个报文交给应用层。
RST：重置连接。
URG：紧急指针有效。
具体过程如下：
SYN：发起一个新连接，一般开始的时候产生一个，后面如果没有新连接就不会产生。
seq：seq序号是一个随机数，但是在往后的客户端的起始序列都在这个基础上+1，服务器也一样。
ACK：受到客户端的连接请求就标志为1，然后将ack确认序号根据客户端发起的序列号确定下来。
最开始的时候，客户端和服务端都出于关闭状态，主动打开连接的是客户端，被动打开连接的是服务器。
- TCP服务器进程先创建传输控制块TCB，时刻准备接受客户端进程的连接请求，这个时候服务器进入了LISTEN（监听）状态。
- TCP客户端进程也是先创建TCB，然后向服务器发送报文请求，报文首部SYN=1，表示发起了新连接，同时选择了一个随机的初始序列号x，这个时候TCP客户端进程进入了SYN-SENT（同步已发送状态）。TCP规定，SYN=1的报文段不可以携带数据，但是会消耗掉一个序号。
- TCP服务器如果受到了请求报文后，若同意连接，则向客户端发起确认报文，此时报文中SYN=1，ACK先产生=1，确认号ack=x+1，同时自己也要初始化一个序列号seq=y，此时TCP服务器进程进入到了SYN-RCVD（同步收到）状态，这个报文不能携带数据，但是要消耗掉一个序号。
- TCP客户端收到确认后，还要向服务器给出确认。确认的报文ACK=1，ack=y+1，自己的序列号seq=x+1，此时TCP连接已经建立，客户端进入ESTABLISHED（已连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据就不消耗序号。
- 当服务器受到了客户端的确认后也进入了ESTABLISHED（已确认）状态，之后双方就可以开始通信了。
我们用虚拟机server1,server2做个实验，使用tcpdump抓包查看
在server2上发布内容，用server1查看，另启一台server1抓包查看握手情况
server1 IP 172.25.10.1 server2 IP 172.25.10.2
tcpdump -i eth0 -S host 172.25.10.1 and 172.25.10.2
-i 指定网卡
-S 获取ack绝对值（不加该参数相对值为1）
host <ip> and <ip> 截获两个ip对应主机之间的通信
让server1上客户端，server2当服务器，一台server1抓包，另一台server1查看server2的http发布内容
可以看到前三次为tcp的三次握手，中间是HTTP服务启动
第一次握手开始：
客户端发送seq=x SYN=1新连接到服务器上，客户端进入SYN-SENT已发送状态
第二次握手开始：
服务器接收到请求报文，同意连接，发出确认报文，ACK=1，SYN=1，确认序号ack=x+1，初始化序列号seq=y，此时服务器进入SYN-RVCD同步收到状态
第三次握手开始：
客户端接收到服务器的确认报文，给服务器给出自己的确认信号，确认报文ACK=1，ack=y+1，序列号seq=x+1
当HTTP服务OK之后，便可通信
提问：为什么是三次握手而不是两次？
回答：因为客户端和服务器都需要确定对方的收发能力良好。
第一次客户端发送，客户端知道自己的发送能力是OK的，服务器接收到了以后知道客户端发送能力OK，自己接受能力OK。然后第二次握手，服务器知道自己发送能力OK，客户端收到之后，知道自己接收能力OK，服务端发送OK。第三次握手，服务端接收到客户端的确认报文后，知道了自己的发送和接收能力都OK，客户端的接收和发送能力也OK，就可以建立连接了。
三次握手的主要原因：
三次握手可以阻止历史重复连接的初始化
三次握手可以同步双方的初始序列号
三次握手可以避免资源浪费
四次挥手（断开连接）
数据传输完毕之后，双方即可释放连接，最开始的时候，客户端和服务器都处于确认状态，然后客户端进行主动关闭，服务器被动关闭。
FIN:释放一个连接。
ACK：确认序列号有效。
比如客户端的初始化序列号ISA=100，服务器初始化的序列号ISA=300，TCP连接成功后客户端总共发送了1000字节的数据，服务器在客户端发FIN报文前回复了2000个字节的数据。
第一次挥手：
客户端进程发出连接释放报文，并且停止发送数据，释放数据报文首部，FIN=1，其序列号seq=1101（100+1000+1，序列号等于初始化序列号+发送的字节数+1，其中的1是建立连接时占用的一个序列号）。
第二次挥手：
服务器接收到客户端发送的FIN报文后给客户端回复确认报文,确认报文包含ACK标志位（ACK=1 ），确认号ack=1102（seq+1），序列号seq=2300（300+2000，这里不需要加1），此时服务端处于关闭等待状态，而不是立即给客户端发送FIN报文，这个状态需要持续一段时间，这是因为服务器可能还有数据没有发送完毕。
第三次挥手：
服务器将最后的数据（比如有100字节）发送完毕，然后就会向客户端发送FIN报文和ACK标志位，确认号ack=1102和第二次挥手的ack一样，序列号seq=2400（2300+100）
第四次挥手：
客户端收到服务端发的FIN报文后，向服务端发出确认报文，确认报文中ACK=1，ack=2401，seq=1102
因为四次挥手中间有数据的传输，所以序列号要发送变化，三次握手时没有考虑数据，所以不需要给序列号加上数据。
问题
1.如果客户端和服务端已经建立了连接，但是客户端突然发生故障怎么办？
TCP设有一个保活计时器，计时器的时间通常设置的是2小时，服务器每次收到客户端的请求后都会复位计时器，客户端如果出现故障，服务器两小时没有收到任何来自客户端的任何数据，服务器就会给客户端发送一个探测报文，每隔75秒发送一次，若连续发送10次探测报文仍无反应，则认为客户端出现故障，关闭连接。
2.为什么客户端最后还要等待2MSL？
MSL为“最长报文段寿命”，2MSL为来回的最长时间,要考虑到丢包的情况，如果第四次挥手的报文丢失，服务端没有收到客户端的确认报文就会重新发送第三次挥手的报文，所以要等待最长2MSL的时间来确认服务端收到了确认报文。
3.三次握手过程可以携带数据吗？
第一次和第二次无法携带数据，只有第三次可以，这是因为第一二次握手时客户端和服务器还没有连接，服务器容易收到攻击，第三次握手时，客户端已经处于连接状态，可以携带数据。
4.创建连接时，为什么客户端还要再发送一次确认报文呢？
主要是防止之前没有发送过去导致失效的报文突然又传送到了服务器，从而会产生错误。
所以要进行三次握手，就算是失效的报文传送过来了，服务器再发送回客户端，但是客户端不会回复，服务器就不会连接了。