传输层之UDP与TCP

2020-04-05  本文已影响0人  飞翃荷兰人

事先声明一下,本文所讲的内容,基本来自于 计算机网络自顶向下方法 这本书,和一些自己的理解,这本书有些内容已经陈旧了,所以如有错误,欢迎勘正。
从内容来说,udp相对较少,我们从udp开始讲起。

UDP协议

首先需要声明一下udp最显著的特点是它是一个无连接的协议,那什么是无连接的呢?简单来说就是发送端发完之后就什么都不管了,接收端能不能收得到不在我的考虑范围之内。如果是一个有连接的协议的话,发送端和接收端会维持一个单独的网络端口专门对这一个有连接的请求进行数据处理。从计算机的实际操作来讲:所谓的有连接还是无连接,就是指的是需不需要经过三次握手这一个建立连接的过程。
下面来通过udp的数据报来分析一下udp到底能做些什么事情?

源端口号 目的端口号
长度 检验和
应用数据(报文)

可以看到,udp的报文段里面是带有长度信息的,而且它还有一个经过运算之后得到的一个校验和,校验和计算方式是将比特字求和之后,再位取反。接收端接收到udp数据报的时候,他会去校验udp的数据和校验和能否对的上,以防止中间数据变脏。
但是如果数据变脏了,接收端到底要不要丢弃,不同的udp有不同的实现方式。从这种校验和的有损加工方式可以看得出来,接收端只有校验数据有没有被变更的能力,但是没有纠正的能力。

TCP协议

TCP协议设计的太复杂了,有点不知道从何说起,下面就从整个TCP的生命周期从前到后的顺序讲,先是最老生常谈的三次握手。下面引入一张TCP三次握手的图

三次握手

image.png

这边先讲一个基本的约定,默认情况下,发起方是客户端,接收方是服务端。一些TCP报文字段含义:

字段名 表示
URG 紧急指针是否有效。为1,表示某一位需要被优先处理
ACK 确认号是否有效,一般置为1。
PSH 提示接收端应用程序立即从TCP缓冲区把数据读走。
RST 对方要求重新建立连接,复位。
SYN 请求建立连接,并在其序列号的字段进行序列号的初始值设定。建立连接,设置为1
FIN 希望断开连接。

三次握手过程:

三次握手的抓包

image.png

为什么要三次握手

谈一个老生常谈的问题,三次握手为什么必须是三次?能不能是两次或者四次?
答案是两次不够,四次冗余,三次是让客户端和服务器端确定双方都已经做好准备的最少的次数。

这里贴一个知乎大佬的回答,写的不错:https://www.zhihu.com/question/24853633

流量控制与拥塞控制

流量控制机制和拥塞控制机制是一对相对容易被搞混的概念,流量控制是一个端和端之间的概念,指的是接收端没有能力及时处理发送端发出的字节流,所以要对发送端的每次发送的数据窗口大小作限定。而拥塞控制指的是网络带宽被占光了,如果继续按照当前速度发送的话,就会发生大量的丢包,所以要对发送端的发送速度做限制。

流量控制

接收端接收数据的时候,可能并不会对数据进行立马处理,所以就需要一个缓存去存放着这些收到的数据,如果发送端发送得过快就会造成接收端缓存不够用,由于TCP是全双工的,两端都会发送和接收数据,所以两端都要维持一个接收窗口,这个接收窗口的作用是告诉对方我还有多大的缓存空间,不要传超过这个大小的数据过来。

拥塞控制

拥塞控制一般是在两个层面上做处理的:

这里主要讲tcp的拥塞控制

快速重传与超时重传

注意:TCP发生重传时会将超时时间设置为之前的两倍,因为网络已经拥堵了,不控制的话网络会更加拥堵。

丢包事件

要么出现超时(超过一定时间没有收到ACK信息),要么收到来自接收方的三次冗余ACK。

拥塞控制算法

首先介绍几个概念:待会用得到,现在不用知道是做什么的

拥塞控制算法

总结: 慢开始,线性增,乘性减

image.png
滑动窗口机制
滑动窗口是一个如图所示的窗口: image.png

可以分为以下四个部分:


image.png
tcp的发送端的发送窗口大小是由流量控制,拥塞控制决定的,滑动窗口机制和确认重传机制是绑定的,举个例子,接收端发送ack = 56的报文过来,发送端就要从56开始发一定大小的数据过去,当然,这只是个举例,实际上,tcp一次会发多个数据过去。
image.png

学习自:https://www.zhihu.com/question/32255109

小结

滑动窗口 + 流量控制 + 拥塞控制 = TCP维持连接

四次挥手

image.png

课外小知识:

上一篇下一篇

猜你喜欢

热点阅读