utp与tcp

tcp与udp的区别

1.tcp基于连接，发送数据前要先建立连接。udp不需要

2.tcp是可靠的，有重传/序号/确定机制/滑动窗口保证顺序和正确。udp不能保证

3.tcp是一对一的。udp支持一对一，一对多，多对多

4.tcp比较耗费资源。udp效率更高

5.tcp基于流模式，udp基于数据报模式

tcp与udp的使用场景

对数据完整性和准确性要求较高时使用tcp

例如：文件传输，邮件

而对实时性和效率要求较高时使用udp

例如：视频通话，直播

tcp与udp的优缺点

tcp优点：

• 可靠稳定：tcp传输数据前后有三次握手建立连接，在传输数据时，有确定，窗口，重传，拥堵控制等，在数据传完后，还会断开连接节约系统资源

tcp缺点：

• 速度慢，效率低，占用系统的资源率高：建立连接，确认机制，重传机制，拥堵机制都会消耗大量时间，有这么多机制，在实现时容易被利用和攻击

udp优点：

• 速度快，比tcp安全：没有建立连接，确认机制，重传机制，拥堵机制等，是一个无状态的传输协议，没有这些机制，udp较tcp被攻击者利用的漏洞就少很多，但也会被其他攻击

udp缺点：

• 不可靠不稳定，没有tcp的机制，在网络质量不好时可能会丢包

udp为什么会丢包，怎么解决

1.发送频率太快

虽然每一个包的大小都没超过标准，但频率太快，连续发送中间也没sleep，可能会丢包

可以通过设置socket接收缓冲解决

2.包过大

包的大小超过限制，可能会超过接收者的缓存，导致丢包

可以通过设置socket接收缓冲解决，或用send方法把大包切割为小包，可以多次切割

TCP是如何确保可靠传输的

• 连接管理：有三次握手，四次挥手

• 校验和：防止数据被破坏，发送方在发送数据前计算检验和，接收方收到收据后以同样的方式计算，然后进行对比，（两方时要其中一方取反的）如果不一致，传输有误，如果一致，也不一定传输成功

• 确认应答：防止丢包，tcp传输时将每个字节的数据都进行了编号（序列号（不会导致分片乱序）），每次接收方接收到数据后，会给传输方进行确认应答，发送ACK报文，里面包括对应的确认序列号，告诉发送方收到了哪些数据，下一次的数据从哪发

• 超时重传：防止丢包，发送方发送数据，迟迟没有得到传输方的应答（ACK报文），这是就会重传，两种原因（没接收到，接收到了但没发出去），重传时发送方发送数据，接收方接收，如果已经有了就直接丢弃，然后再确认应答

• 流量控制：（窗口滑动）：tcp协议的报头信息中，有一个16位字段的窗口大小，数字越大，证明我们接收方能接收的空间越大，接收端在确认应答时会写入窗口大小，发送方根据应答的窗口大小的改变来改变自己的发送速度，如果窗口大小为0，发送方停止发送，并定期向接收端发送窗口探测数据段，让接收端把窗口大小发送给发送方

• 拥堵控制：（拥堵窗口）：tcp引入慢启动，防止一开始数据传输过多导致丢包，发送方刚开始定义拥堵窗口为1，每次收到ACK应答时，拥堵窗口加1，然后在发送数据前将拥堵窗口与接收端反馈的窗口大小对比取小的作为实际发送窗口。最开始拥堵窗口是指数增长，超过阈值后线性增长，一旦造成网络拥堵（发生了超时重传），拥堵窗口变成1。 

 tcp三次握手

在socket编程中，客户端执行connect()时，将触发三次握手。

刚开始客服端处于closed的状态，服务器处于listen状态。

第一次握手：客户端给服务端发送一个SYN报文，并指明客户端的初始化序列号ISN（x），此时客户端处于SYN_SEND状态。

第二次握手：服务器接收到客户端的SYN报文后，会以自己的SYN报文作为应答，同时会把客户端的ISN+1作为ACK的值，表示自己已经收到了客户端的SYN，并指定了自己的初始化序列号ISN（y），此时服务器处于SYN_RCVD。

第三次握手：客户端收到SYN报文之后，会发送一个ACK报文，也是把服务器中的ISN+1作为ACK的值，表示已经收到了服务端的SYN报文，此时客户端处于ESTABLISHED状态，服务器收到ACK报文后，也处于ESTABLISHED

为什么不是两次握手

正面理解三次握手

第一次握手：客户端发包，服务端收到

证明：客户端的发送能力和服务端的接收能力正常

第二次握手：服务端发包，客户端收到

证明：客户端的发送和接收能力正常，服务端的发送和接收能力正常，但是服务器并不知道客户端的接收能力是否正常

第三次握手：客户端发送，服务端接收

证明：全部正常

三次握手可以携带数据吗？

第一次不可以，太容易收到攻击，给服务器分析数据花费大量时间

第二次不可以，太容易收到攻击，给客户端分析数据花费大量时间

第三次可以，客户端已经知道服务端的发送接收能力正常，已经建立连接。

SYN攻击？

SYN泛洪攻击，就是客户端在短时间内伪造大量不存在的IP地址，并向服务器不断的发送SYN包，服务器回复确定并等待客户端确定，由于IP地址不存在，服务器需要不断的重发直到超时，这些SYN包将长时间占用请求队列，导致正常的SYN由于队列满而被丢弃，引起网络拥堵甚至系统瘫痪

tcp三次握手最后一个包丢失会发生什么？

服务器：

最后一个包丢失，服务端没接收到确定，处于SYN_RECV，此时会根据tcp的超时重传机制进行重传，重新发送SYN+ACK，以便客户端重新发送ACK包，如果重复超过指定次数（可以设置），仍未收到客户端ACK应答，那么服务器将自动关闭这个连接

客户端：

如果客户端成功接收到SYN+ACK，说明连接已经建立。如果第三次握手丢包，客户端将接收到服务器端RST包响应，方能感知到服务器出错。

 

1.长连接

Client方与Server方先建立通讯连接，连接建立后 不断开， 然后再进行报文发送和接收。

2.短连接

Client方与Server每进行一次报文收发交易时才进行通讯连接，交易完毕后立即断开连接。

 

TCP的粘包原因和解决

udp不会粘包，因为他有消息边界

1.发送端需要等缓冲区满时才发包（使用指令puah，强制让数据立即发送出去，但降低了网络发送效率，影响应用程序的性能）

2.接收方不及时接收缓冲区中的包（人为控制分多次接收，然后合并，但应用程序的效率较低）

3.接收方创建一预处理线程，对接收到的数据包进行预处理，将粘连的包分开。

 tcp四次挥手

客户端和服务端都可以主动发起挥手

刚开始双方都处于ESTABLISHED状态，假如是客户端先发起挥手请求

第一次挥手：客户端发送一个FIN报文，报文中会指定一个序列号，客户端处于FIN_WAIT1状态。

第二次挥手：服务端收到FIN报文，然后发送ACK报文，把客户端的序列号+1作为ACK的序列号，表明已经收到客户端报文，服务端处于CLOSE_WAIT状态。此时tcp处于半关闭状态，客户端到服务端连接释放。客户端收到服务端的确定后，进入FIN_WAIT2状态，等待服务端发出的连接释放报文段。

第三次挥手：如果服务端也想断开连接，就要和客户端第一次挥手一样，发送FIN报文，并且指定一个序列号。此时服务端处于LAST_ACK状态。‘

第四次挥手：客户端收到FIN之后，发送一个ACK报文作为应答，同样是把服务端的序列号+1作为ACK报文的序列号，此时客户端处于TIME_WAIT状态。需要等待一会（2MSL）,确保服务端接收到报文后进入CLOSED状态，服务端收到ACK报文后，关闭连接，处于CLOSED状态。

 

 为什么不是三次挥手

在第二次挥手和第三次挥手之间，当服务端收到FIN报文时，很可以不会立即关闭SOCKET，所以只能先回复一个ACK报文，让客户端知道已经收到。只有等到所以的报文都发送完毕时，服务端才能发送FIN报文，因此不能一起发送。

第四次释放连接时，为什么等待2MSL

为了保证客户端发送的ACK报文能到达服务端。因为这个报文可能会丢失，导致服务端接收不到客户端的确定报文，服务端会超时重传FIN，再次让客户端确认，然后客户端和服务端都能正常关闭。假设不等待2MSL，客户端发送完ACK后直接关闭，如果ACK丢失，服务器就无法正常的进入关闭连接状态。