TCP协议三次握手四次挥手

TCP有哪些过程？

a. 建立连接
b. 数据传输
c. 终止连接

TCP三次握手和四次挥手的过程？

SYN,ACK是什么？

SYN：请求建立连接（含有同步序列号的标志位的数据，TCP建立连接时，将这个“位”置1）
ACK：针对SYN的确认应答

FIN是什么？

FIN：发送端完成发送任务“位”，当TCP完成数据传输需要断开时，提出断开的一方将这“位”置1

三次握手的过程？

百度百科：
第一次
第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
第二次
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。
完成三次握手，客户端与服务器开始传送数据

为什么是三次次握手？

https://mp.weixin.qq.com/s/NIjxgx4NPn7FC4PfkHBAAQ:
TCP 为什么是三次握手，而不是两次或四次？
原创： 车小胖谈网络 车小胖谈网络 2018-09-13
记得第一次看TCP握手连接的时候，有同样的疑问，我的疑问是，为何不是两次呢？
后来随着对网络的理解深入，明白TCP报文是交由IP网络来负责运输，IP网络并不能保证TCP报文到达目的地，既然IP网络是指望不上了，那TCP就自力更生吧，TCP必须依赖自身的努力来保证数据传输的可靠。
TCP看似复杂，其实可以归纳为以下5种报文：
（1） SYN
（2） Data （唯一携带用户数据）
（3） FIN
（4） Reset
（5） ACK
其中1、2、3分别为建立连接、数据传输、断开连接，这三种报文对方接收到一定要ACK确认，为何要确认，因为这就是可靠传输的依赖的机制。如果对方在超时时间内不确认，发送方会一直重传，直到对方确认为止、或到达重传上限次数而Reset连接。
4、5 为重置连接报文、确认ACK报文，这两种报文对方接收到要ACK确认吧？不需要！自然发送方也不会重传这2种类型的报文。
为何Reset报文不需要ACK确认?
因为发送Reset报文的一端，在发送完这个报文之后，和该TCP Session有关的内存结构体瞬间全部释放，无论对方收到或没有收到，关系并不大。
如果对方收到Reset报文，也会释放该TCP Session 的相关内存结构体。
如果对方没有收到Reset 报文，可能会继续发送让接收方弹射出Reset报文的报文，到最后对方一样会收到Reset 报文，并最终释放内存。
为何ACK报文不需要ACK确认?
这里的ACK报文，是指没有携带任何数据的裸ACK报文，对方收到这样的ACK报文，自然也不需要ACK。否则，对方为了ACK己方的ACK，那己方收到对方的ACK，也要ACK对方的ACK，这就是一个死循环，永无止息。
所以为了避免这个死循环，一律不允许ACK对方的裸ACK报文。
有同学会说，按照这么说，TCP连接应该是四次消息交互啊。
1.A 发送SYN 报文给B，这是第一次报文交互。
2.B发送ACK确认A的SYN报文，这是第二次报文交互
3.B发送自己的SYN报文给A，这是第三次报文交互
4.A需要ACK确认B的SYN报文，这是第四次报文交互
以上的演绎没有问题，但是报文2、3为何要分开发送呢？增加了延迟不说，同时还白白浪费了网络的带宽，完全可以将报文2、3合并起来，不就是在报文2的ACK状态位的位置置“1”就结了吗？
这就是三次消息交互的由来！
原文:
TCP作为一种可靠传输控制协议，其核心思想：既要保证数据可靠传输，又要提高传输的效率，而用三次恰恰可以满足以上两方面的需求！
TCP可靠传输的精髓：TCP连接的一方A，由操作系统动态随机选取一个32位长的序列号（Initial Sequence Number），假设A的初始序列号为1000，以该序列号为原点，对自己将要发送的每个字节的数据进行编号，1001，1002，1003…，并把自己的初始序列号ISN告诉B，让B有一个思想准备，什么样编号的数据是合法的，什么编号是非法的，比如编号900就是非法的，同时B还可以对A每一个编号的字节数据进行确认。如果A收到B确认编号为2001，则意味着字节编号为1001-2000，共1000个字节已经安全到达。
同理B也是类似的操作，假设B的初始序列号ISN为2000，以该序列号为原点，对自己将要发送的每个字节的数据进行编号，2001，2002，2003…，并把自己的初始序列号ISN告诉A，以便A可以确认B发送的每一个字节。如果B收到A确认编号为4001，则意味着字节编号为2001-4000，共2000个字节已经安全到达。
一句话概括，TCP连接握手，握的是啥？
通信双方数据原点的序列号！
以此核心思想我们来分析二、三、四次握手的过程。
A <——-> B
四次握手的过程：
1.1 A 发送同步信号SYN + A’sInitial sequence number
1.2 B 确认收到A的同步信号，并记录A’s ISN 到本地，命名 B’s ACK sequence number
1.3 B发送同步信号SYN + B’s Initial sequence number
1.4 A确认收到B的同步信号，并记录B’s ISN 到本地，命名 A’s ACK sequence number
很显然1.2和1.3 这两个步骤可以合并，只需要三次握手，可以提高连接的速度与效率。
二次握手的过程：
2.1 A 发送同步信号SYN + A’sInitial sequence number
2.2 B发送同步信号SYN + B’sInitial sequence number + B’s ACK sequence number
这里有一个问题，A与B就A的初始序列号达成了一致，这里是1000。但是B无法知道A是否已经接收到自己的同步信号，如果这个同步信号丢失了，A和B就B的初始序列号将无法达成一致。
于是TCP的设计者将SYN这个同步标志位SYN设计成占用一个字节的编号（FIN标志位也是），既然是一个字节的数据，按照TCP对有数据的TCP segment 必须确认的原则，所以在这里A必须给B一个确认，以确认A已经接收到B的同步信号。
有童鞋会说，如果A发给B的确认丢了，该如何？
A会超时重传这个ACK吗？不会！TCP不会为没有数据的ACK超时重传。
那该如何是好？B如果没有收到A的ACK，会超时重传自己的SYN同步信号，一直到收到A的ACK为止。
补充阅读
第一个包，即A发给B的SYN 中途被丢，没有到达B
A会周期性超时重传，直到收到B的确认
第二个包，即B发给A的SYN +ACK 中途被丢，没有到达A
B会周期性超时重传，直到收到A的确认
第三个包，即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的Data。
c. 假定B有数据发送，数据发送不了，会一直周期性超时重传SYN + ACK，直到收到A的确认才可以发送数据。

四次挥手的过程？

百度百科：
由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
（1） TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送。
（2） 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号。
（3） 服务器关闭客户端的连接，发送一个FIN给客户端。
（4） 客户端发回ACK报文确认，并将确认序号设置为收到序号加1。

TCP数据丢失时处理机制