-
传输层概述
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sr7wgTGs-1639618288172)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70.png)]
传输层的功能如下:
- 传输层提供应用进程之间的逻辑通信(即端到端的通信)。
-
与网络层的区别是,网络层提供的是主机之间的逻辑通信。 -
从网络层来说,通信的双方是两台主机,IP 数据报的首部给出了这两台主机的IP地址。 -
但“两台主机之间的通信”实际上是两台主机中的应用进程之间的通信,应用进程之间的通信又称端到端的逻辑通信。 -
这里“逻辑通信”的意思是:传输层之间的通信好像是沿水平方向传送数据,但事实上这两个传输层之间并没有–条水平方向的物理连接。 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vNNYJJZo-1639618288174)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-16380212847322.png)]
- 复用和分用。
- 复用是指发送方不同的应用进程都可使用同一个传输层协议传送数据;
- 分用是指接收方的传输层在剥去报文的首部后能够把这些数据正确交付到目的应用进程。
注意:
- 传输层的复用分用功能与网络层的复用分用功能不同。
- 网络层的
复用 是指发送方**不同协议**的数据都可以封装成IP 数据报发送出去, - 网络层的
分用 是指接收方的网络层在剥去首部后把数据交付给**相应的协议**。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-thNPEmHD-1639618288174)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-16381012416564.png)]
- 传输层还要对收到的报文进行差错检测(首部和数据部分)。
- 网络层只检查
IP 数据报的首部,不检验数据部分是否出错。
- 提供两种不同的传输协议,即面向连接的
TCP 和无连接的UDP 。
- 网络层无法同时实现两种协议(即在网络层要么只提供面向连接的服务,如虚电路;要么只提供无连接服务,如数据报,而不可能在网络层同时存在这两种方式)。
-
传输层的寻址与端口 -
端口的作用
- 端口能够让应用层的各种应用进程将其数据通过端口向下交付给传输层,以及让传输层知道应当将其报文段中的数据向上通过端口交付给应用层相应的进程。
- 端口是传输层服务访问点
(TSAP) ,它在传输层的作用类似于IP 地址在网络层的作用或MAC地址在数据链路层的作用,只不过IP 地址和MAC地址标识的是主机,而端口标识的是主机中的应用进程 - 数据链路层的
SAP 是MAC 地址,网络层的SAP 是IP 地址,传输层的SAP 是端口
OSI layer | SAP |
---|
数据链路层 | MAC 地址 | 网络层 | IP 地址 | 传输层 | 端口 |
传输层使用的是软件端口!!!
- 在协议栈层间的抽象的协议端口是软件端口,它与路由器或交换机上的硬件端口是完全不同的概念。硬件端口是不同硬件设备进行交互的接口,而软件端口是应用层的各种协议进程与传输实体进行层间交互的一种地址。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xY66O6hh-1639618288175)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-16381020407006.png)]
-
socket (套接字)
- 在网络中通过
IP 地址来标识和区别不同的主机,通过端口号来标识和区分一台主机中的不同应用进程 。在网络中采用发送方和接收方的套接字(Socket) 组合来识别端点 。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jp4LQjHH-1639618288176)(D:\photo\photolibrary\20200411135540517.png)]
-
无连接UDP 和面向连接TCP 服务
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4KM7ywSO-1639618288177)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-16381078075012.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-m7m486Xf-1639618288178)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70.png)]
UDP
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-za0e8s1r-1639618288179)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-16381566302965.png)]
相比于TCP,有很多应用更适合用UDP,主要是因为UDP具有如下优点:
-
UDP无须建立连接 * UDP不会引入建立连接的时延。 * 试想如果DNS运行在TCP而非UDP.上,那么DNS的速度会慢很多。 * **HTTP使用TCP**而非UDP,是因为对于基于文本数据的Web网页来说,可靠性 是至关重要的。 -
无连接状态。 * TCP需要在端系统中维护连接状态。此连接状态包括接收和发送缓存、拥塞控制参数和序号与确认号的参数。 * 而UDP不维护连接状态,也不跟踪这些参数。 * 因此,某些专用应用服务器使用UDP 时,一般都能支持更多的活动客户机 。 -
分组首部开销小 * TCP 有20B 的首部 开销,而UDP 仅有8B 的开销。 -
应用层能更好地控制要发送的数据和发送时间。 * UDP没有拥塞控制,因此网络中的拥塞不会影响主机的发送效率 。 * 某些实时应用要求以稳定的速度发送 ,能容忍一些数据的丢失,但不允许有较大的时延 ,而UDP正好满足这些应用的需求。 -
UDP常用于一次性传输较少数据的网络应用 * 如DNS、SNMP 等,因为对于这些应用,若采用TCP,则将为连接创建、维护和拆除带来不小的开销。 * UDP也常用于多媒体应用(如IP 电话、实时视频会议、流媒体等),显然,可靠数据传输对这些应用来说并不是最重要的,但TCP的拥塞控制会导致数据出现较大的延迟,这是它们不可容忍的。 -
UDP提供尽最大努力的交付,即不保证可靠交付 * 但这并不意味着应用对数据的要求是不可靠的,因此所有维护传输可靠性的工作需要用户在应用层来完成。 * 应用实体可以根据应用的需求来灵活设计自己的可靠性机制 。 -
UDP是面向报文的。 * 发送方UDP对应用层交下来的报文 ,在添加首部后就向下交付给IP 层, 既不合并,也不拆分 ,而是保留这些报文的边界; * 接收方UDP对IP 层交上来UDP用户数据报,在去除首部后就原封不动地交付给上层应用进程,一次交付一个完整的报文。 * 因此报文不可分割,是UDP数据报处理的最小单位 。
UDP首部格式
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ev8cyS66-1639618288180)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-16381575859557.png)]
各字段意义如下:
- 源端口。源端口号。16位,2 Byte.在需要对方回信时选用,不需要时可用全0。
- 目的端口。目的端口号。16位,2 Byte.这在终点交付报文时必须使用到。
- 长度。UDP数据报的长度(包括首部和数据),其最小值是8 Byte (仅有首部)。
- 校验和。检测UDP数据报在传输中是否有错。有错就丢弃。该字段是可选的,当源主机不想计算校验和时,则直接令该字段为全0。
当传输层从IP 层收到UDP数据报时
根据首部中的目的端口,把UDP数据报通过相应的端口.上交给应用进程
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KGw4rxFI-1639618288180)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-16381577290419.png)]
如果接收方UDP发现收到的报文中的目的端口号不正确(即不存在对应于端口号的应用进程),那么就丢弃该报文,并由ICMP发送“端口不可达”差错报文给发送方 。
UDP校验
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IbAo0iZz-1639618288181)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-163826192982711.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OZSFkIvL-1639618288182)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-163826201857713.png)]
二进制反码求和:
对一个**无符号的数,先求其反码,然后从低位到高位,按位相加,有溢出则向高位进1(和一般的二进制法则一样),若最高位有进位,则向最低位进1.**
这里不分正负数,直接每个为都取反。关于二进制反码求和运算需要说明的一点是,先取反后相加与先相加后取反,得到的结果是一样的。
本例子中采用先相加后取反. 规则是从低到高位逐列进行计算,0和0加得0, 0和1加得1, 1和1加得0但要产生一个进位1,加到下一列,若最高位产生了进位,则最后得到的结果要加1。
0 1 0 1 0
+1 1 0 1 1
————————————————
=0 0 1 0 1(高位产生进位,所以需要再加1)
+0 0 0 0 1
————————————————
=0 0 1 1 0
UDP校验和计算步骤:
- 让第一行和第二行做二进制反码运算。(0+0=0, 1+0=1, 1+1=1(进位)留下0)
- 将第一行和第二行的结果(即第一部的结果)与第三行做二进制反码计算,以此类推。
- 最终运算结果取反,得到校验和。
1001 1001 0001 0011 //伪首部源IP地址前16位
0000 1000 0110 1000 //伪首部源IP地址后16位
1010 1011 0000 0011 //伪首部目的IP地址前16位
0000 1110 0000 1011 //伪首部目的IP地址后16位
0000 0000 0001 0001 //伪首部UDP协议字段代表号17,前面8位是填充0
0000 0000 0000 1111 //伪首部UDP长度字段
0000 0100 0011 1111 //UDP头部源IP地址对应的进程端口号
0000 0000 0000 1101 //UDP头部目的IP地址对应的进程端口号
0000 0000 0000 1111 //UDP头部UDP长度字段
0000 0000 0000 0000 //UDP头部UDP检验和
0101 0100 0100 0101 //数据字段
0101 0011 0101 0100 //数据字段
0100 1001 0100 1110 //数据字段
0100 0111 0000 0000 //数据字段+填充0字段
计算过程:
1001 1001 0001 0011 //伪首部源IP地址前16位
0000 1000 0110 1000 //伪首部源IP地址后16位
————————————————
1010 0001 0111 1011
1010 1011 0000 0011 //伪首部目的IP地址前16位
————————————————
0100 1100 0111 1110
(进位到最低位)
0100 1100 0111 1111
0000 1110 0000 1011 //伪首部目的IP地址后16位
————————————————
0101 1010 1000 1010
0000 0000 0001 0001 //伪首部UDP协议字段代表号17,前面8位是填充0
————————————————
0101 1010 1001 1011
0000 0000 0000 1111 //伪首部UDP长度字段
————————————————
0101 1010 1010 1010
0000 0100 0011 1111 //UDP头部源IP地址对应的进程端口号
————————————————
0101 1110 1110 1001
0000 0000 0000 1101 //UDP头部目的IP地址对应的进程端口号
————————————————
0101 1110 1111 0110
0000 0000 0000 1111 //UDP头部UDP长度字段
————————————————
0101 1111 0000 0101
0000 0000 0000 0000 //UDP头部UDP检验和
————————————————
0101 1111 0000 0101
0101 0100 0100 0101 //数据字段
————————————————
1011 0011 0100 1010
0101 0011 0101 0100 //数据字段
————————————————
0000 0110 1001 1110
(进位到最低位)
0000 0110 1001 1111
0100 1001 0100 1110 //数据字段
————————————————
0100 1111 1110 1101
0100 0111 0000 0000 //数据字段+填充0字段
————————————————
1001 0110 1110 1101
(最后取反)
0110 1001 0001 0010(√)
接收端校验和换成上述计算(二进制反码计算)结果,如果全为1,则无差错.
-
TCP协议
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Qeb1nUab-1639618288182)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LEwBWtcv-1639618288183)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-16383649036262.png)]
TCP报文段的首部格式
TCP传送的数据单元称为报文段 。一个TCP报文段分为TCP首部和TCP数据两部分,整个TCP报文段作为IP数据报的数据部分封装在IP数据报中- 其首部的前20B是固定的。TCP报文段的首部最短为20B,后面有4N字节是根据需要而增加的选项,通常长度为4B的整数倍。
- TCP报文段既可以用来运载数据,又可以用来建立连接、释放连接和应答。
**序列号**用来指向本方打算发送的数据的第一个byte的序列号, **确认号**用来确认数据的接收, 指向已收到序列的下一个byte, 表示之后希望收到此序号开头的数据
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-N6BPsC1g-1639618288183)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-16383650080014.png)]
源端口和目的端口字段 。各占2B。端口是运输层与应用层的服务接口,运输层的复用和分用功能都要通过端口实现。序号字段 。占4B。TCP是面向字节流的(即TCP传送时是逐个字节传送的),所以TCP连接传送的数据流中的每个字节都编上一个序号。序号字段的值指的是本报文段所发送的数据的第一个字节的序号。确认号字段 。占4B,是期望收到对方的下一个报文段的数据的第一个字节的序号。若确认号为N,则表明到序号N- 1为止的所有数据都已正确收到。数据偏移(即首部长度) 。占4位,这里不是IP数据报分片的那个数据偏移,而是表示首部长度,它指出**TCP报文段的数据起始处距离TCP报文段的起始处有多远**。“数据偏移”的单位是32位(以4B为计算单位)。因此当此字段的值为15时,达到TCP首部的最大长度60B.保留字段 。占6位,保留为今后使用,但目前应置为0,该字段可以忽略不计。紧急位URG 。URG= 1时,表明紧急指针字段有效。它告诉系统报文段中有紧急数据,应尽快传送(相当于高优先级的数据)。但URG需要和紧急指针配套使用 ,即数据从第一个字节到紧急指针所指长度的字节 就是紧急数据 。确认位ACK 。只有**当ACK= 1时确认号字段才有效。当ACK=0时,确认号无效。TCP规定,在连接建立后所有传送的报文段都必须把ACK置1.**推送位PSH (Push) 。 接收TCP收到PSH= 1的报文段,就尽快地交付给接收应用进程而不再等到整个缓存都填满后再向上交付。复位位RST (Reset) 。RST=1时,表明TCP连接中出现严重差错(如主机崩溃或其他原因),必须释放连接,然后再重新建立运输连接。同步位SYN 。同步SYN= 1表示这是一个连接请求或连接接收报文 。当SYN=1, ACK=0 时,表明这是一个连接请求 报文,对方若同意建立连接,则在响应报文中使用SYN=1, ACK=1 。即SYN= 1表示这是一个连接请求或连接接收报文。终止位FIN (Finish) 。用来释放一个连接。FIN= 1表明此报文段的发送方的数据已发送完毕,并要求释放传输连接。窗口字段 。占2B。接收方允许对方发送的数据量,接收方的数据缓存空间是有限的,可以用窗口值让发送方设置其发送窗口的大小,单位为字节。校验和 。占2B。校验和字段检验的范围包括首部和数据两部分。在计算校验和时,和UDP一样,要在TCP报文段的前面加上12B的伪首部(只需将UDP伪首部的第4个字段,即**协议字段的17改成6**,其他的和UDP一样)。紧急指针字段 。占16 位,指出在本报文段中紧急数据共有多少字节(紧急数据放在本报文段数据的最前面)。选项字段 。长度可变。TCP最初只规定了一种选项,即最大报文段长度(Maximum SegmentSize,MSS)。MSS是TCP报文段中的数据字段的最大长度。窗口扩大、时间戳、选择确认填充字段 。这是为了使整个首部长度是4B的整数倍。填充0.
TCP连接管理
每条TCP连接通过通信两端的两个端点( 即两个套接字) 确定。
TCP连接采用客户服务器方式,主动发起连接建立的应用程序叫做客户,而被动等待连接建立的应用程序叫服务器
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kjNBjlbo-1639618288184)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-16383657208486.png)]
三次握手
ack是首部里的确认号字段
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KHVhF5AG-1639618288184)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-16383657550908.png)]
- seq为序号字段,标明本次报文段数据部分的第一个字节的序号
- **ack**是首部里的
确认号字段 ,告诉对方我接下来应该接收的数据是从字节序号ack开始的数据 - ACK是确认位,0时
确认号字段ack 无效,1时确认号字段ack 有效 - SYN是同步位
TCP提供的是全双工通信,因此通信双方的应用进程在任何时候都能发送数据。
- 服务器端的资源是在完成第二次握手时分配的
- 而客户端的资源是在完成第三次握手时分配的,这就使得服务器易于受到SYN洪泛攻击。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-i6kZjk5k-1639618288185)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-163836650429610.png)]
以上攻击也被称为DoS(Denial of service)攻击,使服务器拒绝服务的攻击.
其中D(Distributed)DoS是指通过病毒使得大量主机执行脚本攻击服务器,造成服务器瘫痪.
TCP连接释放----四次握手
参与TCP连接的两个进程中的任何- 一个都能终止该连接。TCP连接释放的过程通常称为四次握手
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-o2CFddXF-1639618288185)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-163841266749512.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OX36ezFQ-1639618288186)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-163841269482714.png)]
-
客户机打算关闭连接时,向其TCP发送一个连接释放报文段, 并停止发送数据,主动关闭TCP连接,该报文段的FIN标志位被置1, seq=u, 它等于前面已传送过的数据的最后一个字节的序号加1 (FIN报文段即使不携带数据,也要消耗一个序号)。
TCP 是全双工的,即可以想象为一条TCP连接上有两条数据通路。
? 发送FIN报文时,发送FIN的一端不能再发送数据,即关闭了其中一条数据通路,但对方还可以发送数据。
-
服务器收到连接释放报文段后即发出确认,确认号是ack=u+1,而这个报文段自己的序号是v,等于它前面已传送过的数据的最后一个字节的序号加1 。 但服务器若发送数据,客户机仍要接收,即从服务器到客户机这个方向的连接并未关闭 。 -
:若服务器已经没有要向客户机发送的数据,就通知TCP释放连接,此时其发出FIN= 1的连接释放报文段 。 -
客户机收到连接释放报文段后,必须发出确认 。在确认报文段中,ACK字段被置为1,确认号ack=w+1,序号seq=u+1.此时TCP连接还未释放,必须经过时间等待计时器设置的时间2MSL后,A才进入连接关闭状态 。
TCP连接建立和释放的总结如下
连接建立。分为3步: ①SYN=1, ACK=0, seq=x。 ②SYN=1, ACK=1, seq=y, ack=x+1。 ③SYN=0, ACK=1,seq=x+1, ack=y+1。
连接阶段 | SYN | ACK | seq序号字段 | ack确认号字段 (希望获得的对方字段值,此前的已经收到) |
---|
1(client) | 1 | 0 | x | | 2(server) | 1 | 1 | y | x+1 | 3(client) | 0 | 1 | x+1 | y+1 |
释放连接。分为4步:
①FIN=1, seq= u ②ACK=1, seq=v, ack=u+1。 ③FIN=1,ACK=1, seq=w,ack=u+1。 ④ACK=1, seq=u+1, ack=w+ 1。
释放阶段 | FIN | ACK | seq序号字段 | ack确认号字段 (希望获得的对方字段值,此前的已经收到) |
---|
1(client) | 1 | 0 | u | | 2(server) | 0 | 1 | v | u+1 | 3(server) | 1 | 0 | w | u+1 | 4(client) | 0 | 1 | u+1 | w+1 |
为什么TCP释放连接需要四次?
TCP建立连接要进行三次握手,而断开连接要进行四次。这是由于TCP的半关闭造成的。因为TCP连接是全双工的(即数据可在两个方向上同时传递)所以进行关闭时每个方向上都要单独进行关闭。这个单方向的关闭就叫半关闭。当一方完成它的数据发送任务,就发送一个FIN来向另一方通告将要终止这个方向的连接。
TCP之所以设置为半关闭, 即关闭需要(请求+确认)×2=4次握手, 是因为全双工的TCP协议发送双方可能不会同时结束, 其中一方结束了需要等待另一方发完全部数据,再断开连接. 开启时则没有这个要求(同时开启即可,没有先发后发之说)
TCP的每一方的创建和断开请求,另一方都需要回复ACK.(3次握手的时候服务器的ACK和建立请求放在了一次里)
TCP可靠传输
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AWyF10bE-1639618288186)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-163841595395416.png)]
分为4步, 1.校验 2.序号 3.确认 4.重传
-
校验 增加伪首部, 每16位(2B)进行二进制反码求和(先求和再求反码), 得出校验位 -
序号 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-k5EiVNLL-1639618288186)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-163841612113418.png)] -
确认 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mOm6ZvlJ-1639618288187)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-163841621250520.png)]
? 序列号**用来发送数据, **确认号用来接收数据的确认
- 重传
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ttf2pstF-1639618288187)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-163841660791622.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KB8TS9Ep-1639618288188)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-163841665955424.png)]
类似累计确认
TCP流量控制
-
在通信过程中,**接收方**根据自己接收缓存的大小,动态地调整发送方的发送窗口大小,这称为接收窗口rwnd , 即调整TCP报文段首部中的“窗口”字段值 ,来限制发送方向网络注入报文的速率。
RWND(Receiver Window)滑动窗口
-
同时,**发送方**根据其对当前网络拥塞程序的估计而确定的窗口值,这称为拥塞窗口cwnd ,其大小与网络的带宽和时延密切相关。
CWND(Congestion Window)拥塞窗口
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-E3eRKFTC-1639618288188)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-163841732850326.png)]
- rwnd 即接收方允许连续接收的最大能力,单位是字节。
- 发送方A总是根据最新收到的rwnd值来限制自己发送窗口的大小,从而将未确认的数据量控制在rwnd大小之内,保证A不会使B的接收缓存溢出。
A的发送窗口的实际大小取rwnd和cwnd中的最小值
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CI9B6Xl2-1639618288189)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-163841761497928.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oSkzByG0-1639618288189)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-163841762495830.png)]
传输层和数据链路层的流量控制的区别是:
- 传输层定义
端到端 用户之间的流量控制,数据链路层定义两个中间的相邻结点 的流量控制。 - 另外,
数据链路层 的滑动窗口协议的窗口 大小不能动态变化 ,传输层 的则可以动态变化 。
TCP拥塞控制
什么是拥塞控制?
- 所谓
拥塞控制,是指防止过多的数据注入网络(过多的设备接入网路,请求通信),保证网络中的路由器或链路不致过载 。出现拥塞时,端点并不了解到拥塞发生的细节,对通信连接的端点来说,拥塞往往表现为通信时延的增加。
拥塞控制和流量控制也有相似的地方,即它们都通过控制发送方发送数据的速率来达到控制效果
拥塞控制与流量控制的区别
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-674JNWzl-1639618288190)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-163841833828332.png)]
例如:
- 某个链路的传输速率为10Gb/s,某巨型机向一台PC以1Gb/s的速率传送文件,显然网络的带宽是足够大的,不存在拥塞问题,但如此高的发送速率将导致PC可能来不及接收,因此必须进行
流量控制 。 - 但若有100万台PC在此链路上以1Mb/s的速率传送文件,则现在的问题就变为网络的负载是否超过了现有网络所能承受的范围。就像我们上网一样,有时候加载会很慢,提示访问请求过多,请稍后再试,就是网络产生了拥塞,带宽小,一下不能支持给多个请求终端发送数据。
为了更好地对传输层进行拥塞控制,因特网建议标准定义了以下4种算法:慢开始、拥塞避免、快重传、快恢复。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9sHg0ut6-1639618288191)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-163841908705434.png)]
- 慢开始与拥塞避免
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dugEitxq-1639618288191)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-163841920840336.png)]
慢开始算法
- 在TCP刚刚连接好并开始发送TCP报文段时,先令拥塞窗口cwnd= 1,即一个最大报文段长度MSS.每收到一个对新报文段的确认后,将cwnd加1,即增大一个 MSS.用这样的方法逐步增大发送方的拥塞窗口cwnd,可使分组注入网络的速率更加合理。
- 使用慢开始算法后,每经过一个传输轮次(即往返时延RTT),拥塞窗口cwnd就会加倍,即cwnd的大小指数式增长。这样,慢开始一直把拥塞窗口cwnd增大到一个规定的
慢开始门限ssthresh(阈值) ,然后改用拥塞避免算法 。
例如,A向B发送数据,发送时A的拥塞窗口为2,那么A一次可以发送两个TCP报文段,经过一个RTT后(也称一个传输轮次 ),A收到B对刚才两个报文的确认,于是把拥塞窗口调整为4,下一次发送时就可一次发送4个报文段。
拥塞避免算法
- 拥塞避免算法的做法如下:发送端的拥塞窗口cwnd每经过- -一个往返时延RTT就增加一个MSS的大小,而不是加倍,使cwnd按线性规律缓慢增长(即加法增大),而当出现一次超时(网络拥塞)时,令慢开始门限ssthresh等于当前cwnd的一半(即乘法减小)。
根据cwnd的大小执行不同的算法,可归纳如下: ●当cwnd < ssthresh时,使用慢开始算法。 ●当 cwnd > ssthresh时,停止使用慢开始算法而改用拥塞避免算法。 ●当cwnd = sthresh时,既可使用慢开始算法,又可使用拥塞避免算法(通常做法)。
网络拥塞的处理
-
网络出现拥塞时,无论是在慢开始阶段还是在拥塞避免阶段,只要发送方检测到**超时事件**的发生(未按时收到确认,重传计时器超时),就要把慢开始门限ssthresh设置为出现拥塞时的发送方的cwnd值的一半(但不能小于2)。 -
然后把拥塞窗口cwnd重新设置为1,执行慢开始算法。这样做的目的是迅速减少主机发送到网络中的分组数,使得发生拥塞的路由器有足够时间把队列中积压的分组处理完。 -
拥塞避免并不能完全能避免拥塞。利用以上措施要完全避免网络拥塞是不可能的。拥塞避免是指在拥塞避免阶段把拥塞窗口控制为按线性规律增长,使网络比较不容易出现拥塞。
乘法减小与加法增大
“乘法减小” 是指不论是在慢开始阶段还是在拥塞避免阶段,只要出现一次超时(即很可能出现了网络拥塞),就把慢开始门限值ssthresh设置为当前拥塞窗口值的一半。网络频繁出现拥塞时,ssthresh 值就下降得很快,以大大减少注入网络的分组数。“加法增大” 是指执行拥塞避免算法后,在收到对所有报文段的确认后(即经过一个 RTT),就把拥塞窗口cwnd增加一个MSS大小,使拥塞窗口缓慢 增大,以防止网络过早出现拥塞。
快重传和快恢复
快重传和快恢复算法是对慢开始和拥塞避免算法的改进。
快重传
- 在TCP可靠传输机制中,
快重传技术 使用了冗余ACK来检测丢包的发生 。同样,冗余ACK也用于网络拥塞的检测 (丢了包当然意味着网络可能出现了拥塞)。快重传并非取消重传计时器,而是在某些情况下可更早地重传丢失的报文段。 - 当发送方连续收到三个重复的ACK报文时,
直接重传对方尚未收到的报文段,而不必等待那个报文段设置的重传计时器超时 。
快恢复
- 发送端收到连续三个冗余ACK (即重复确认)时,执行
“乘法减小”算法 ,把慢开始门限ssthresh 设置为出现拥塞时发送方cwnd的一半 - 与慢开始(慢开始算法将拥塞窗口cwnd设置为1)的
不同之处 是,它把cwnd的值设置为慢开始门限ssthresh改变后的数值,然后开始执行拥塞避免算法(“ 加法增大”) ,使拥塞窗口缓慢地线性增大。 由于跳过了cwnd从1起始的慢开始过程,所以被称为快恢复 。
作为对比,虚线为慢开始的处理过程。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ym3paVKM-1639618288191)(D:\photo\photolibrary\watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkxNDYwNA==,size_16,color_FFFFFF,t_70-163841983551338.png)]
- 在
流量控制 中,发送方发送数据的量由接收方决定,而在拥塞控制 中,则由发送方自己通过检测网络状况来决定。 - 实际上,
慢开始、拥塞避免、快重传和快恢复几种算法 应是同时应用在拥塞控制机制之中的 - 当发送方检测到超时的时候,就采用慢开始和拥塞避免,
- 当发送方接收到冗余ACK时,就采用快重传和快恢复。
注意: 发送方发送窗口的实际大小 由流量控制 和拥塞控制 共同决定。
因此,当题目中同时出现接收端窗口(rwnd) 和拥塞窗口(cwnd) 时,发送方实际的发送窗口大小是由rwnd和cwnd中较小的那一个确定的。
|