tcp三次握手四次挥手通俗解释：TCP的三次拉握手
tcp三次握手四次挥手通俗解释：TCP的三次拉握手推送PSH，当两个应用进程进行交互式通信时，有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应，这时候就将PSH=1；确认ACK，仅当ACK=1时，确认号字段才有效。TCP规定，在连接建立后所有报文的传输都必须把ACK置1；数据偏移，占4位，它指出TCP报文的数据距离TCP报文段的起始处有多远；保留，占6位，保留今后使用，但目前应都位0；紧急URG，当URG=1，表明紧急指针字段有效。告诉系统此报文段中有紧急数据；
一、要建立TCP需要三次握手才能建立链接，而断开连接则需要四次挥手。整个过程如下图所示：
- TCP报文部首
TCP提供的是一种可靠的数据传输。它保证接收到的所有字节与发送的字节相同，并且按接收到字节的顺序和发送字节的顺序相同。由于网络传输的不可靠性，TCP采用确认和重发技术等技术来保证传输的可靠性。这一技术要求接收端接收到正确的数据包要向发送端进行确认。发送端发送数据包后会保持一个重发计时器，如果发送端在重发计时器超时后还没有收到接收端发来的确认则重传为确认的数据包。
TCP是传输层协议，TCP数据包是封装在IP报文之中的。TCP数据包分TCP数据部分和TCP数据包头部。TCP数据部分用来装载应用层交下来的数据。TCP头部在不计算可选字段的情况下为20个字节。源端口和目的端口，各占2个字节，分别写入源端口和目的端口；序号，占4个字节，TCP连接中传送的字节流中的每个字节都按顺序编号。例如，一段报文的序号字段值是 301 ，而携带的数据共有100字段，显然下一个报文段（如果还有的话）的数据序号应该从401开始；
确认号，占4个字节，是期望收到对方下一个报文的第一个数据字节的序号。例如，B收到了A发送过来的报文，其序列号字段是501，而数据长度是200字节，这表明B正确的收到了A发送的到序号700为止的数据。因此，B期望收到A的下一个数据序号是701，于是B在发送给A的确认报文段中把确认号置为701；
数据偏移，占4位，它指出TCP报文的数据距离TCP报文段的起始处有多远；
保留，占6位，保留今后使用，但目前应都位0；
紧急URG，当URG=1，表明紧急指针字段有效。告诉系统此报文段中有紧急数据；
确认ACK，仅当ACK=1时，确认号字段才有效。TCP规定，在连接建立后所有报文的传输都必须把ACK置1；
推送PSH，当两个应用进程进行交互式通信时，有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应，这时候就将PSH=1；
复位RST，当RST=1，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立连接；
同步SYN，在连接建立时用来同步序号。当SYN=1，ACK=0，表明是连接请求报文，若同意连接，则响应报文中应该使SYN=1，ACK=1；
终止FIN，用来释放连接。当FIN=1，表明此报文的发送方的数据已经发送完毕，并且要求释放；
窗口，占2字节，指的是通知接收方，发送本报文你需要有多大的空间来接受；
检验和，占2字节，校验首部和数据这两部分；
紧急指针，占2字节，指出本报文段中的紧急数据的字节数；
选项，长度可变，定义一些其他的可选的参数。
三、控制位：字段长为 8 位，每一位从左到右分别为 CWR、ECE、URG、ACK、PSH、RST、SYN、FIN。这些控制标志也叫做控制位。当他们的对应位上值为 1 时，具体含义如下：
CWR：CWR 标志与后面的 ECE 标志都用于 IP 首部的 ECN 字段，ECE 标志为 1 时，则通知对方已将拥塞窗口缩小；
ECE：若其值为 1 则会通知对方，从对方到这边的网络有阻塞。在收到数据包的 IP 首部中 ECN 为 1 时将 TCP 首部中的 ECE 设为 1.；
URG：该位设为 1，表示包中有需要紧急处理的数据，对于需要紧急处理的数据，与后面的紧急指针有关；
ACK：该位设为 1，确认应答的字段有效，TCP规定除了最初建立连接时的 SYN 包之外该位必须设为 1；
PSH：该位设为 1，表示需要将收到的数据立刻传给上层应用协议，若设为 0，则先将数据进行缓存；
RST：该位设为 1，表示 TCP 连接出现异常必须强制断开连接；
SYN：用于建立连接，该位设为 1，表示希望建立连接，并在其序列号的字段进行序列号初值设定；
FIN：该位设为 1，表示今后不再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换 FIN 位置为 1 的 TCP 段。每个主机又对对方的 FIN 包进行确认应答之后可以断开连接。不过，主机收到 FIN 设置为 1 的 TCP 段之后不必马上回复一个 FIN 包，
四、TCP连接的建立（三次握手）三次握手流程：
A 的 TCP 向 B 发送 连接请求报文段，其首部中的同步位 SYN = 1 ，并随机选择一个序号 seq = x ，表明传送数据时的第一个数据字节序号为 x。
TCP 协议规定，SYN 置 1 的报文段不能携带数据，但是要消耗一个序号
B 的 TCP 收到连接请求报文段后，如果同意，则发挥连接同意报文
B 在连接同意报文段中应使 SYN = 1 ，使 ACK = 1 其确认号ack = x 1 自己随机选择一个序号seq = y
3. A 收到此报文后向 B 给出确认，其 ACK = 1 ，确认号 ack = y 1，seq = x 1
A 的TCP通知上层应用进程，连接已经建立
- B 的 TCP 收到主机A的确认后，也通知其上层应用进程：TCP连接已经建立
三次握手示意图
五、TCP四次挥手
数据传输结束后，通信的双方都可以释放连接，现在A和B都处在ESTABLISHED状态，假设有客户端A请求释放连接，则释放连接过程如下：
A的应用进程先向其TCP发送释放报文段，并停止再发送数据，主动关闭TCP连接。A把连接释放报文段首部的终止控制位FIN置为1，其序号为seq=u，u等于前面已发送过的数据最后一个字节序号加1。A进入FIN-WAIT-1（终止等待1）状态，等待B的确认。TCP规定，FIN报文段即使不带数据，也要消耗一个序号。
B收到连接释放报文段后即发出确认，确认号是ack=u 1，而这个报文号自己的序号是seq=v，v等于B已传送过的数据的最后一个字节的序号加1。B进入CLSOE-WAIT（关闭等待）状态。TCP服务器进程这时通知上层应用。因而A到B这个方向的连接就释放了，这时TCP处于半关闭（half-close）状态，即A已经没有数据要发送给B了，但是B如果发送数据给A，A任然要接受。因为B到A这个方向的连接并未关闭，这个状态可能会持续一段时间。A收到来自B的确认后，就进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。
若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接。这时B发出的连接释放报文段首部必须使FIN=1。现假设B的序号为w（在半关闭状态B可能又发送了一些数据）。B还必须重复上次已发送过的确认号ack=u 1。这时B就进入LAST-ACK（最后确认）状态，等待A的确认。
A在收到B的连接释放报文段后，必须对此发出确认。在确认报文段中把ACK置为1，确认号ack=w 1，而自己的序号是seq=u 1（前面发送过的FIN报文要消耗一个序号）。然后进入到TIME-WAIT（时间等待）状态。此时TCP连接还没有释放。必须经过时间等待计时器（TIME-WAIT timer）设置的时间2MSL后，A才进入CLOSED状态。MSL叫做最长报文段寿命（Maximum Segment Lifetime），RFC 793建议设置为2分钟（TCP允许不同的实现更改MSL值），即默认TIME_WAIT状态持续4分钟后，A进入CLOSED状态，才能开始建立下一个新的连接，当A撤销相应的传输控制块TCB后，就结束了TCP连接。
以上就是TCP四次挥手的全过程。
为什么A在TIME-WAIT状态必须等待2MSL的时间？
为了保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段可能丢失，因而使处在LAST-ACK状态的B收不到对已发送FIN ACK报文段的确认。B会超时重传这个FIN ACK报文段，而A就能在2MSL时间内收到这个重传的FIN ACK报文段。接着A重传一次ACK确认，重新启动2MSL计时器。最后A和B都正常进入CLOSED状态。如果A在TIME-WAIT不等待一段时间，而是发送ACK后马上进入CLOSED状态，一旦ACK丢失，B由于收不到ACK确认，所以会重传FIN ACK报文段，但此时A已经进入CLOSED状态，自然无法再发送ACK确认。所以B也无法正常进入CLOSED状态。
可以使本次连接所有报文段在网络上消失。A发送完最后一个ACK后，再等待2MSL，就可以使本连接持续的时间内所有产生的报文段都从网络上消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。
除了时间等待计时器外，TCP还有一个保活计时器（keepalive timer）。当TCP连接完成后，客户端突然出现故障，无法发送报文段。保活计时器可以避免服务器白白等下去。服务器每收到一次请求，重置一下保活计时器，时间设置通常2小时。若2小时没有收到客户端请求，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若连续发送10个探测报文段仍无客户端响应，服务器就认为客户端出现故障，接着关闭这个连接。
六、TCP 重传、滑动窗口、流量控制、拥塞控制
重传机制由于TCP的下层网络（IP）可能出现丢失、重复或失序的情况，TCP协议提供可靠数据传输服务。为保证数据传输的正确性，TCP会重传其认为已丢失（包括报文中的比特错误）的包。TCP使用两套独立的机制来完成重传，一是基于时间，二是基于确认信息的构成。
第一种基于时间的重传在其下的数据链路层、网络层乃至同层的UDP协议都有使用，即设置一个计时器来判断数据传输是否超时，当然它们对于计时器时间的设定规则有所不同。本文主要聚焦于TCP的第二种重传机制。
滑动窗口窗口滑动协议是TCP使用的一种流量控制方法。该协议允许发送方在停止并等待接收确认报文前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。只有在接收窗口向前滑动时（与此同时也发送了确认），发送窗口才有可能向前滑动。收发两端的窗口按照以上规律不断地向前滑动，因此这种协议又称为滑动窗口协议。
滑动窗口协议：
TCP协议的使用
维持发送方/接收方缓冲区 缓冲区是 用来解决网络之间数据不可靠的问题，例如丢包，重复包，出错，乱序
在TCP协议中，发送方和接受方通过各自维护自己的缓冲区。通过商定包的重传机制等一系列操作，来解决不可靠的问题。
流量控制
流量控制是通过滑动窗口来实现的。 滑动窗口分为发送端窗口和接收端窗口。窗口有大小限制，窗口大小是接收端用来告诉发送端目前接收端能接收的最大字节数。窗口的大小在TCP协议头里，大小为16位。然而在TCP协议的可选项里，还可以定义窗口的比例因子，因此实际的窗口大小可以超过64KB。窗口的含义实际上就是接收缓冲区的大小。发送窗口维护了发送端发送的已被接收端ACK的序号，以及已经发送的最大序号，这样就可以知道还能发送多少的新数据。接收窗口维护了已经ACK的序号，以及所有接收到的包序号。窗口大小在特定的一次连接通信过程中，大小是不变的。而滑动窗口是一种机制，滑动窗口的大小在发送端代表的是可发送的数据大小，在接收端代表的是可接收的数据大小，它们是动态变化的。
拥塞控制
拥塞控制是通过拥塞窗口来实现的。拥塞窗口指发送端在一个RTT内可以最多发送的数据包数。拥塞控制一般包括慢启动、拥塞避免两个阶段。慢启动阶段是从1开始指数增长到限定大小的过程。拥塞避免阶段时超过限定大小之后线性增加的过程，以及发现丢包后将拥塞窗口改为1，并把限定大小减半的过程。
