1、TCP

tcp在三次握手建立连接后可进行可靠传输,主要是依靠超时重传、应答确认、滑动窗口和拥塞控制机制实现的。这些机制与TCP头部有紧密联系~
image.png
来看看TCP头部的构造!
image.png
确认应答:在三次握手、四次挥手和数据传输过程中,一端收到来自对端的信号时通过回复ACK通知对方已接收到信息。

超时重传:TCP协议在发送数据以后,每个报文都会有一个定时器,在定时器指定的时间内接受端对于这个报文段的确认报文如果没有到达,就会重新发送一次,并且这次的定时器时间为上次的两倍。

滑动窗口:TCP流量控制的一种手段。它会通知对方本端的TCP接受缓冲区还能容纳多少字节的数据,对方就可以控制发送数据的速度。

流量控制:如果发送者发送数据过快,接收者来不及接收,就会有分组丢失。为了避免分组丢失,控制发送端的发送速度,使得接收端来得及接收。

使用TCP进行通信的双方,发送端会将数据写入发送缓冲区,接收端从接收缓冲区中读取数据。发送端执行的写操作次数和接收端进行的读操作次数之间没有任何的数量关系,这就是TCP的字节流服务:应用程序对数据的接收和发送是没有边界限制的。多次发送的数据可以被接收端一次接收。
image.png

三次握手四次挥手

刚开始客户端处于 closed 的状态,服务端处于 listen 状态。然后
1、第一次握手:客户端给服务端发一个 SYN 报文,并指明客户端的初始化序列号 ISN(c)。此时客户端处于 SYN_Send 状态。
客户端的发送能力、服务端的接收能力是正常的。
2、第二次握手:服务器收到客户端的 SYN 报文之后,会以自己的 SYN 报文作为应答,并且也是指定了自己的初始化序列号 ISN(s),同时会把客户端的 ISN + 1 作为 ACK 的值,表示自己已经收到了客户端的 SYN,此时服务器处于 SYN_REVD 的状态。
服务端的接收、发送能力,客户端发送能力是正常的。
3、第三次握手:客户端收到 SYN 报文之后,会发送一个 ACK 报文,当然,也是一样把服务器的 ISN + 1 作为 ACK 的值,表示已经收到了服务端的 SYN 报文,此时客户端处于 establised 状态。
客户端的接收能力正常
4、服务器收到 ACK 报文之后,也处于 establised 状态,此时,双方以建立起了链接。

1、确认双方的接受能力、发送能力是否正常。
2、指定自己的初始化序列号,为后面的可靠传送做准备。
3、如果是 https 协议的话,三次握手这个过程,还会进行数字证书的验证以及加密密钥的生成到。

刚开始双方都处于 establised 状态,假如是客户端先发起关闭请求,则:
1、第一次挥手:客户端发送一个 FIN 报文,报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。
2、第二次握手:服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序列号值 + 1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于 CLOSE_WAIT状态。
3、第三次挥手:如果服务端也想断开连接了,和客户端的第一次挥手一样,发给 FIN 报文,且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
4、第四次挥手:客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答,且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值,此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态
5、服务端收到 ACK 报文之后,就处于关闭连接了,处于 CLOSED 状态。

这里特别需要主要的就是TIME_WAIT这个状态了,,为什么客户端发送 ACK 之后不直接关闭,而是要等一阵子才关闭。这其中的原因就是,要确保服务器是否已经收到了我们的 ACK 报文,如果没有收到的话,服务器会重新发 FIN 报文给客户端,客户端再次收到 ACK 报文之后,就知道之前的 ACK 报文丢失了,然后再次发送 ACK 报文。
至于 TIME_WAIT 持续的时间至少是一个报文的来回时间。一般会设置一个计时,如果过了这个计时没有再次收到 FIN 报文,则代表对方成功就是 ACK 报文,此时处于 CLOSED 状态。

1、 为什么建立连接协议是三次握手,而关闭连接却是四次握手呢?
这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后,它可以把ACK和SYN(ACK起应答作用,而SYN起同步作用)放在一个报文里来发送。但关闭连接时,当收到对方的FIN报文通知时,它仅仅表示对方没有数据发送给你了;但未必你所有的数据都全部发送给对方了,所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后,再发送FIN报文给对方来表示你同意现在可以关闭连接了,所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。
2、 为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态?
这是因为:虽然双方都同意关闭连接了,而且握手的4个报文也都协调和发送完毕,按理可以直接回到CLOSED状态(就好比从SYN_SEND状态到ESTABLISH状态那样);但是因为我们必须要假想网络是不可靠的,你无法保证你最后发送的ACK报文会一定被对方收到,因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文,而重发FIN报文,所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。 TCP 与 UDP 区别 - 图4

点击 查看大示意图

  • 三次握手的作用:

①确认双方的接受能力、发送能力是否正常;
②指定自己的初始化序列号,为之后的可靠传输做准备(如果是 https 协议
的话,三次握手的过程还会进行数字证书的验证及加密密钥的生成)

  • SYN 泛洪攻击

在第二次握手服务器处于 SYN_RECV 状态时容易被攻击。服务器第一次收到客户端的 SYN 之后,就会处于 SYN_REC 状态,此时双方还没有完全建立其 连接,服务器会把此种状态下请求连接放在一个队列里,我们把这种队列称之为半连接队列(已经完成三次握手,建立起连接的就会放在全连接队列中)。如果此阶段下有同一客户端不断的向服务器发送连接,半连接队列被全部占用,就会
导致其他客户端不能再连接服务器。(syn 溢出攻击/syn 泛洪)

2、UDP

UDP是无连接、不可靠的、数据报服务
UDP协议不需要建立连接,只要使用UDP协议的程序执行起来,两端可以通过ip和端口号直接进行交互。自然也就没有TCP协议中的listen、accept函数。

UDP服务器编程流程:
image.png

image.png

UDP客户端编程流程:
image.png

UDP数据报服务sendto发送数据和recvfrom接收数据的次数相等。recvfrom接收数据时必须将sendto发送的数据一次接收完,否则本次剩余数据将被丢弃。sendto一次发送数据的长度应该小于等于recvfrom读取数据的大小。(UPD也有发送缓冲区和接收缓冲区)
image.png

image.png

UDP的头部结构:
image.png
相比TCP头部,UDP头部就简单了很多。TCP和UDP头部都存在的部分:源端口号、目的端口号、校验码。

3、TCP与UDP区别总结:

TCP面向连接,可靠的,有序的,以字节流方式发送数据(如打电话要先拨号建立连接);
TCP通过校验和,重传控制,序号标识,滑动窗口、确认应答实现可靠传输。如丢包时的重发控制,还可以对次序乱掉的分包进行顺序控制。
每一条TCP连接只能是点到点的;

UDP是无连接的,不保证可靠交付,面向报文,即发送数据之前不需要建立连接
UDP具有较好的实时性,工作效率比TCP高,适用于对高速传输和实时性有较高的通信或广播通信。
UDP支持一对一,一对多,多对一和多对多的交互通信

TCP对系统资源要求较多,UDP对系统资源要求较少。

3、为什么UDP有时比TCP更有优势?

UDP以其简单、传输快的优势,在越来越多场景下取代了TCP,如实时游戏。

(1)网速的提升给UDP的稳定性提供可靠网络保障,丢包率很低,如果使用应用层重传,能够确保传输的可靠性。

(2)TCP为了实现网络通信的可靠性,使用了复杂的拥塞控制算法,建立了繁琐的握手过程,由于TCP内置的系统协议栈中,极难对其进行改进。

采用TCP,一旦发生丢包,TCP会将后续的包缓存起来,等前面的包重传并接收到后再继续发送,延时会越来越大,基于UDP对实时性要求较为严格的情况下,采用自定义重传机制,能够把丢包产生的延迟降到最低,尽量减少网络问题对游戏性造成影响。