TCP与UDP，TCP 三次握手四次挥手

TCP：

1. 面向于连接（类似于打电话，进行数据传输之前需要先建立连接）。
2. 准确可靠的。也就是说，通过TCP连接传送的数据，无差错、不丢失、不重复，且保证按序到达。
3. TCP面向字节流，实际上TCP把数据看成是一串无结构的字节流。
4. 每一条TCP连接只能是点到点的。（只支持一对一）
5. TCP 首部开销20字节。
6. TCP 的逻辑通信信道是双全工的可靠信道。

为满足TCP协议的这些特点，TCP协议做了如下的规定：

①数据分片：在发送端对用户数据进行分片，在接收端进行重组，由TCP确定分片的大小并控制分片和重组；

②到达确认：接收端接收到分片数据时，根据分片数据序号向发送端发送一个确认；

③超时重发：发送方在发送分片时启动超时定时器，如果在定时器超时之后没有收到相应的确认，重发分片；

④滑动窗口：TCP连接每一方的接收缓冲空间大小都固定，接收端只允许另一端发送接收端缓冲区所能接纳的数据，TCP在滑动窗口的基础上提供流量控制，防止较快主机致使较慢主机的缓冲区溢出；

⑤失序处理：作为IP数据报来传输的TCP分片到达时可能会失序，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层；

⑥重复处理：作为IP数据报来传输的TCP分片会发生重复，TCP的接收端必须丢弃重复的数据；

⑦数据校验：TCP将保持它首部和数据的检验和，这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到分片的检验和有差错，TCP将丢弃这个分片，并不确认收到此报文段导致对端超时并重发。

 主要功能：

TCP为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认（ACK）；如果发送端实体在合理的往返时延（RTT）内未收到确认，那么对应的数据（假设丢失了）将会被重传。

• 在数据正确性与合法性上，TCP用一个校验和函数来检验数据是否有错误，在发送和接收时都要计算校验和；同时可以使用md5认证对数据进行加密。

• 在保证可靠性上，采用超时重传和捎带确认机制。

• 在流量控制上，采用滑动窗口协议，协议中规定，对于窗口内未经确认的分组需要重传。

在拥塞控制上，采用广受好评的TCP拥塞控制算法（也称AIMD算法）。该算法主要包括四个主要部分：

• 慢启动
• 拥塞避免
• 快速重传
• 快速恢复 

UDP:

1. 无需连接，即发数据之前不需要建立连接（类似于短信）。
2. 不可靠的。UDP尽最大的努力去交付，不保证数据的准确性。UDP数据量大。
3. UDP是面向报文的。UDP没有拥塞控制，即在网络出现拥塞时也不会使主机降低发送的速率。（对实时应用很有用，如IP电话、实时视频会议等）
4. UDP支持一对一、一对多、多对一、多对多的交互通信。
5. UDP首部开销8个字节。
6. UDP是不可靠信道。

总结来说tcp相对可靠，数据准确，适用于精准的场合。UDP数据量大，并且不会因为网络拥塞而降低速度，更适用于视频、视频电话等场合（丢失几个字节肉眼也无法发现）。

功能：

为了在给定的主机上能识别多个目的地址，同时允许多个应用程序在同一台主机上工作并能独立地进行数据包的发送和接收，设计用户数据报协议UDP。

UDP使用底层的互联网协议来传送报文，同IP一样提供不可靠的无连接数据包传输服务。它不提供报文到达确认、排序、及流量控制等功能。

UDP Helper可以实现对指定UDP端口广播报文的中继转发，即将指定UDP端口的广播报文转换为单播报文发送给指定的服务器，起到中继的作用。

 协议对比：

UDP和TCP协议的主要区别是两者在如何实现信息的可靠传递方面不同。TCP协议中包含了专门的传递保证机制，当数据接收方收到发送方传来的信息时，会自动向发送方发出确认消息；发送方只有在接收到该确认消息之后才继续传送其它信息，否则将一直等待直到收到确认信息为止。与TCP不同，UDP协议并不提供数据传送的保证机制。如果在从发送方到接收方的传递过程中出现数据包的丢失，协议本身并不能做出任何检测或提示。因此，通常人们把UDP协议称为不可靠的传输协议。

TCP 是面向连接的传输控制协议，而UDP 提供了无连接的数据报服务；TCP 具有高可靠性，确保传输数据的正确性，不出现丢失或乱序；UDP 在传输数据前不建立连接，不对数据报进行检查与修改，无须等待对方的应答，所以会出现分组丢失、重复、乱序，应用程序需要负责传输可靠性方面的所有工作；UDP 具有较好的实时性，工作效率较 TCP 协议高；UDP 段结构比 TCP 的段结构简单，因此网络开销也小。TCP 协议可以保证接收端毫无差错地接收到发送端发出的字节流，为应用程序提供可靠的通信服务。对可靠性要求高的通信系统往往使用 TCP 传输数据。 

使用TCP的场合就是：
当对网络通信质量有要求的时候，比如： 整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，如QQ，游览器， HTTP,HTTPS,FTP等传输文件的协议，POP,SITP等邮件传输的协议。

使用UDP的场合是：
当对我拿过来通信质量要求不高的时候，要求网络通讯能尽量的快，这时就可以使用UDP，比如qq语音，qq视频FTFP 。

TCP的三次握手和四次挥手

tcp报文结构

 如图就是tcp的报文结构，其中每一行都代表了32位（4字节），其中重点是32位序号（seq）（tcp为了数据的准确，给每个字节的数据都配备了唯一的序号（客户端和服务器都拥有各自的序号））、32位确认序号（ack）（比如客户端向服务器发送一个了一个数据（有序号z），那么服务器在应答时，必须带上相应的z+1的32位确认序号，至于为什么要+1，我的理解是这个数据消耗了一个序号，那么下一个就是z+1）、应答信号（ACK）、请求连接信号（同步信号）（SYN）、请求释放（FIN）。

32位序号：TCP有重传机制，如果发现回应的序号（ack确认序号）不对，那就重新开始上一个动作，不管是连接请求还是，正在的发送数据都一样。（也就是说每一次发送的数据都会有一个回应，这就使得tcp的传输速度很慢）

三次握手

• 最开始的时候客户端和服务器都处于CLOSED状态（关闭态）。客户端主动打开连接，服务器被动打开连接。
• 服务器先创建TCB（传输控制模块），接着进入LISTEN（监听）状态，随时等待客户端的连接
• （第一次握手）客户端也是先创建TCB，接着主动发起连接请求（SYN置一，并且随机抽取一个序号x，seq=x），此时客户端已经进入了SYN-SENT（同步已发送状态（已发送等待状态）），等待服务器的回应。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
• （第二次握手）服务器接收到了客户端的连接请求，向它回应（SYN=1,因为是回应 应答信号ACK也要置一，并且确认回应序号ack=x+1，同时服务也给出自己的随机序号y），此时服务器进入SYN-RCVD（同步已接收到等待）状态。这个报文也不能携带数据，但是同样要消耗一个序号。
• （第三次握手）客户端接收到了服务器的回应信号，此时它也要给服务器一个回应信号（应答信号置（ACK=1），应答确认序号ack=y+1,自己的序号seq=x+1），接着客户端进入ESTABLISHED（已建立连接状态），注意：此时只是半连接，因为服务器还没进入连接状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。
• 服务器接收到客户端的应答进入ESTABLISHED（已连接）状态。三次握手就完成了，可以收发数据了哦（通信的序号是从以上动作最后的序号开始）。
   

以上场景，若其中一个没有及时响应（回复）或者接收到的话，（它就会以为自己没有发送能力）发送方就会重复发送，并且重新进入当时所在的状态。直到接收完成，那么这一个动作（发送）才算完成。

 

四次挥手
挥手前：服务器和客户端都处于ESTABLISHED（已连接状态）。

• （第一次挥手）客户端发送完数据了，主动向服务器提出了断开连接的申请（FIN置一，客户端最后一个数据的序号+1 seq=u）。此时客户端进入FIN-WAIT-1（终止等待1）状态。TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
• （第二次挥手）服务器接收到了客户端的断开请求，回应他（应答信号置一ACK=1，应答序号ack=u+1；服务器上一次最后的数据序号+1 seq=v），让客户端知道了自己已经收到了它的断开请求（注意：这里并没有FIN（断开）信号，也就是还没准备好断开），服务器进入CLOSE-WAIT（关闭等待）状态（但是此时服务器并没有准备好断开（他可能还有数据要给客户端），所以要等待一段时间，这一段时间也就是关闭等待状态的时间，那么这一段时间服务器去做什么了呢？服务器通知高层的应用进程，客户端向服务器的方向就释放了）。此时连接是处于**半关闭（单向断开）**的状态，即客户端的往服务器的连接已经断开（就是数据不能发了），但是服务器往客户端的连接并没有释放，服务器要想向客户端发送数据，客户端依然需要接受。
• 客户端接收到服务器的回应，进入FIN-WAIT-1（终止等待2）状态，等待服务器的释放报文信号。在这之前还需要接受服务器发送的最后的数据
• （第三次挥手）服务器发送完数据之后，就给客户端发送释放信号（断开连接）（FIN=1，ACK=1，ack=u+1（第一次挥手后客户端并没有给服务器发送任何信号所以还是u+1），seq=w（上一次传输数据后的序号，假设=w）），服务器进入LAST-ACK（最后确认）状态（等待客户端回应）。此时的FIN报文应该也是要消耗一个序号的，因为下一次是w+1
• （第四次挥手）客户端回应服务器的断开信号（ACK=1，ack=w+1；（自己的序号）seq=u+1）。客户端此时会进入TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗ *∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
• 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

为什么TCP连接的时候是3次？2次不可以吗？

因为需要考虑连接时丢包的问题，如果只握手2次，第二次握手时如果服务端发 给客户端的确认报文段丢失，此时服务端已经准备好了收发数(可以理解服务端 已经连接成功)据，而客户端一直没收到服务端的确认报文，所以客户端就不知 道服务端是否已经准备好了(可以理解为客户端未连接成功)，这种情况下客户端 不会给服务端发数据，也会忽略服务端发过来的数据。

如果是三次握手，即便发生丢包也不会有问题，比如如果第三次握手客户端发的 确认ack报文丢失，服务端在一段时间内没有收到确认ack报文的话就会重新进 行第二次握手，也就是服务端会重发SYN报文段，客户端收到重发的报文段后会 再次给服务端发送确认ack报文。

为什么客户端最后还要等待2MSL？

• 第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
• 第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

为什么建立连接是三次握手，关闭连接确是四次挥手呢？
建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。
简而言之，就是连接时，服务器已经进入LISTEN状态，随时准备迎接客户端信号的到来；而断开的时候客户端请求断开，只是客户端单方面准备好了，服务器可能还有数据要给客户端，也有可能没有，那么服务器就是可以在发送完应答信号后，立即发送断开连接信号（没数据的情况下），也可以发送完应答信号，接着发送数据，再发送断开连接信号（有数据情况下）。

如果已经建立了连接，但是客户端突然出现故障了怎么 办？

TCP设有一个保活计时器，客户端如果出现故障，服务器不能一直等下去，白白 浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通 常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一 个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反 应，服务器就认为客户端出了故障，接着就关闭连接。