TCP三次握手，四次分手

TCP UDP

TCP：1.面向连接（如打电话需要先拨号建立连接）；
2.提供可靠的服务，通过TCP传送的数据，无差错，不丢失，不重复，且按序到达；
3.面向字节流，实际上是TCP把数据看成一连串无结构的字节流；
4.有拥塞控制
5.每一条TCP连接只能是点到点的
6.TCP首部开销20字节
7.TCP是全双工的可靠信道
UDP：1.无连接，发送数据之前不需要建立连接 ；
2. 尽最大努力交付，不保证可靠交付
3. UDP是面向报文的，应用层交给UDP多长的报文，UDP就照样发送，即一次只发送一个报文，
4. UDP没有拥塞控制，因此网络出现拥塞不会使源主机发送速率降低（对实时应用很有用，比如IP电话，视频会议等，允许丢一点数据）
5. UDP支持一对一，一对多，多对一和多对多的交互通信
6. UDP首部开销小，只有3字节
7. UDP是不可靠信道

TCP 三次握手

**Round 1 ** 客户端发送连接请求报文段，不传输数据。
SYN = 1, seq = x （随机）
Round 2 服务器为该TCP连接分配缓存和变量，并向客户端返回确认报文段，允许连接，不传输数据。
ACK = 1, SYN = 1, seq = y（随机），ack = x+1;
Round 3 客户端为TCP连接分配缓存和变量，并向服务器端返回确认的确认，可以携带数据。
SYN = 0, ACK = 1, seq = x+1， ack = y+1；

ACK =1时，确认号有效（这句话的意思是ACK =1, ack就是有效的），在连接建立后，所有传送的报文段都必须把ACK置为1。
SYN=1时，表明是一个连接请求/连接请求接受报文。

为什么是三次握手，而不是两次

在服务器端对客户端的请求进行回应（第二次握手后)，就会理所应当的认为连接已经建立，但如果客户端没有服务器的回应呢，此时客户端仍认为连接未建立，服务器端会对已经建立的连接保存必要的资源，如果出现大量这种情况，服务器会崩溃。

SYN攻击

SYN泛洪攻击，攻击者通过发送TCP SYN，也就是三次握手中的第一个数据包，当服务返回ACK后，该攻击者就不对其进行再确认，那么这个TCP连接就会处于办连接状态，服务器收不到再确认的话，还会重复发送ACK给攻击者，这样就会更加浪费服务器的资源。攻击者回发送非常大量的这种TCP连接，由于每一个都无法完成三次握手，所以在服务器上，这些TCP连接会因为挂起状态而消耗CPU和内存，醉胡服务器可能会死机，就无法为正常用户提供服务了。

四次分手

Round 1 客户端发送连接释放报文段，停止发送数据，主动关闭TCP连接。
FIN = 1, seq = u；
Round 2 服务器端返回一个确认报文段，客户端到服务器这个方向的连接就释放了—半关闭状态。
ACK = 1, seq = v, ack = u+1;—服务器端仍有数据传输
Round 3 服务器端发完数据，就发出连接释放报文段，主动关闭TCP连接
FIN = 1, ACK = 1, seq = w, ack = u+1； —无数据传输
Round 4 客户端回送一个确认报文段，再等到时间等待计时器设置的2MSL（最长报文段寿命）后，连接彻底关闭。
ACK = 1, seq = u+1, ack = w+1;

为什么是四次分手，而不是三次

这是由于服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后。它能够把ACK和SYN（ACK起应答作用。而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它只表示对方没有数据发送给你了。但未必你所有的数据都所有发送给对方了。所以你能够未必会立即会关闭SOCKET,也即你可能还须要发送一些数据给对方之后，再发送FIN报文给对方来表示你允许如今能够关闭连接了。所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

为什么要等待2MSL

很简单，因为最后一次关闭的ACK你永远无法知道对方是否有收到，所以需要等待一个包在网络中存在的最大周期，如果超过这个周期ACK没有发送到对方位置，发送端就会收到丢包命令（这个命令是由网络控制协议发出的），进而可以进行重发，反之则认为对方收到了ACK，结束wait。

TCP保证可靠传输的机制

（1）数据排序
TCP有专门的序号字段，提供数据re-order；
一个字节占一个序号，TCP是按照包来发送的，一个包里面可以装两个字节/三个字节/。。。
序号字段指的是一个报文段第一个字节的序号。

（2） 确认和重传机制
建立连接时，三次握手同步双方的“***+窗口大小信息”，是确认重传，流量控制的基础。
接收方会对收到的数据包进行一个累计确认，在合适的时候发送一个确认报文段，告诉发送方我已经收到了这个信息。
同时接收方有时候也可以在自己有数据需要发送的时候，将这个确认信息捎带着一起发送，就是我们常说的捎带确认。
发送发根据序号判断自己有无按序到达，如果有丢包现象的话，会进行重传。

确认机制和重传机制是密切相关的。TCP的发送方在规定时间内没有收到确认就要重传已发送的报文段，超时重传。
TCP采用自适应算法，动态改变重传时间RTTs（加权平均往返时间）
传输过程中，如果checksum校验失败，丢包或者延时，发送端重传。

冗余ACK：
每当比期望序号大的失序报文段到达时，都发送一个冗余ACK，指明下一个期待字节的序号。
发送方已发送1，2，3，4，5报文段
接收方收到1，返回给1的确认（确认号为2的一个字节）
接收方收到3，仍返回给1的确认（确认号为2的一个字节）
接收方收到4，仍返回给1的确认（确认号为2的一个字节）
接收方收到5，仍返回给1的确认（确认号为2的一个字节）
发送方收到3个对于报文段1的冗余ACK，认为2报文段丢失，重传2号报文段 快速重传。

（3）流量控制（让发送方发送慢点，要让接收方来得及接收）
在通信过程中，接收方根据自己接收缓存的大小，动态的调整发送方发送端口的大小，即接收窗口rwnd（接收方设置确认报文段的窗口字段来将rwnd通知给发送方），发送方的发送窗口取接收窗口rnwd和拥塞窗口cwnd的最小值。

滑动窗口和计时器的使用，TCP窗口中会指明双方能够发送接收的最大数据量，发送方通过维持一个发送滑动窗口来确保不会发生由于发送方报文发送太快接收方无法及时处理的问题。

（4）拥塞控制

TCP的拥塞控制由4个核心算法组成：

“慢开始”（Slow Start）
“拥塞避免”（Congestion avoidance）

“快重传 ”（Fast Retransmit）
“快恢复”（Fast Recovery）