文章目录
目的是总结运输层中两个协议的相关内容(重点TCP)
下面网站是别人的计算机网络知识点总结
https://github.com/Snailclimb/JavaGuide/blob/master/计算机网络与数据通信/计算机网络.md
协议体系结构
OSI:七层协议,从上到下依次是应用层,表示层,会话层,运输层,网络层,数据链路层,物理层;
TCP/IP:四层协议,从上到下依次是应用层,运输层,网络层,网络接口层
运输层概述
简单理解:网络层通过ip找到目标主机,运输层实现应用进程间的数据传输。
运输层应具有复用:发送方:不同的应用进程都可以使用运输层协议传送数据;
分用:接受方:能将报文段交付给正确的应用进程。
运输层的两个协议
UDP:用户数据报协议
TCP:传输控制协议
UDP
UDP协议特点
- 无连接
- 尽最大努力交付:不可靠,
- 面向报文:即不对应用进程传来的数据进行切割;
- 没有拥塞控制:一个应用场景:实时视频会议(拥塞控制会降低源主机发送速率;实时视频允许部分数据丢失)
- 等等
UDP首部格式
包含:源端口,目的端口,长度(=首部长度+数据报长度),检验和,共8个字节
检验和的计算:二进制反码
TCP
TCP协议特点
- 面向连接
- 提供可靠交付的服务
- 提供全双工通信:即每个应用进程在同一时刻既可以是发送方,又可以是接收方
- 面向字节流
- 每一条TCP连接只能有两个端点
端点: 运输层提供端到端的通信,其中端的概念,即是套接字:ip:端口号
传输控制协议TCP概述
停止等待协议
特点:每发送一个分组就停止,等待对方的确认。
缺点:信道利用率非常低
连续ARQ协议
特点:滑动窗口内的数据都可发出,无需等待对方确认;
累积确认:接收方对按序到达的最后一个分组发送确认,表示到这个分组为止的所有分组都已正确收到。
TCP首部格式
首部长度: 20字节+选项部分长度,最大不超过60字节
源端口;目的端口;序号(本次发送的报文段中的第一个字节的序号);确认号(接收端已按序接受到字节,期待发送端下一次发送的字节序号);数据便宜(TCP首部长度);保留;
URG:
ACK:
PSH:
RST:
SYN:
FIN:
窗口:接收方能够接受的字节长度;
检验和;紧急指针(紧急数据的长度);选项;填充
TCP可靠传输的实现
以字节为单位的滑动窗口
超时重传时间选择
确定超时重传的时间。
选择确认SACK
服务器端未按序收到报文段,实现只重传缺少数据;
TCP的流量控制
滑动窗口
传输效率
发送报文段的时机;
TCP的拥塞控制
拥塞原因:对资源的需求的总和 > 可用资源
四个拥塞控制方法
慢开始
拥塞避免
快重传
快恢复
随即早期检测RED
避免全局同步;
TCP的运输链接管理
运输链接有三个阶段:连接建立,数据传送和连接释放。
连接建立
三次握手
服务进程先创建TCB,处理LISTEN状态;
三个过程描述:
- 客户进程创建传输控制模块TCB,向服务进程发送连接请求报文段:SYN = 1 seq = x
SYN报文段不携带信息,消耗一个序号;
之后客户进程处于SYN-SENT状态 - 服务进程收到后,如果同意建立连接,向客户进程确认:SYN = 1, ACK = 1, ack = x + 1, seq = y
不携带信息,同样消耗一个序号;
之后服务进程处于 SYN-RCVD状态(接受 received) - 客户进程收到确认后,再向服务进程给出确认:ACK = 1, ack = y + 1, seq = x + 1
可以不包含信息,如果不包含,则客户进程发送的下一个数据报文段的序号还是x+1
之后客户进程处于ESTABLISHED状态
服务进程接收到该确认后,也进入ESTABLISHED状态。
为什么A(客户进程)还要发送一次确认呢?
防止已失效的连接请求报文段突然又传送到了B(服务进程),因而产生错误。
解释:
A开始发送了一个连接请求报文段m,但该报文段迷失在了网络中(没有丢失,只是卡在了某个地方,产生已失效的连接请求报文段);于是A又发了一个连接请求报文段n,成功建立了连接L1。在L1连接完成数据传输,并释放后,见了鬼了,B又收到了连接请求报文段m,B发出同意建立连接的报文(B也奇怪,不是刚通信完么)。这是如果没有第三步的A的确认,B发送请求后,连接就建立了;而此时A发现自己没有发出建立连接的请求,因此不予理睬B。(B哭唧唧);而B认为连接已建立,一直等待A发送数据,浪费资源。(来自计算机网络——谢希仁 第6版)
而由于需要A的第三步的确认,A不会向B发送数据;B收不到确认,知道A并没有建立连接。
释放链接
四次挥手
开始进程A和进程B都处于ESTABLISHED状态,现在A主动提出管理连接。
四个过程解释:
- A进程发送连接释放报文段,停止发送数据:FIN = 1, seq = u
FIN报文段即使不携带数据,也消耗一个序号;
之后A处于FIN-WAIT-1 状态 - B发出确认: ACK = 1 , ack = u + 1, seq = v
之后B处于CLOSED-WAIT状态
A收到B的确认后,进入FIN-WAIT- 2状态,等待B发出连接释放报文段 - B发出连接释放报文段:FIN = 1, seq = w, ack = u + 1
之后B处于LAST-ACK状态 - A收到B的连接释放报文后,发出确认:ACK = 1 , ack = w + 1, seq = u + 1
之后A处于TIME-WAIT状态。A经过2个MSL(最长报文段寿命)后,才进入CLOSED状态
B收到A的确认后,进入CLOSED状态
为啥A在TIME-WAIT状态必须等待2MSL时间呢?
- 为了保证A发送的最后一个ACK报文段能够到达B;最后A发送的ACK是有可能丢失的,这样B由于收不到对FIN-ACK的确认,就会重传,此时A在这2MSL中就可以接受到重传的报文段,并对该报文段再次发出确认,并重新开始2MSL计时。
但如果A不等待2MSL,直接断开连接,由于ACK的可能丢失,B就收不到确认,而无法正确进入CLOSED状态。 - 防止“已失效的连接请求报文段”出现在本连接中。在2MSL中,本链接持续的时间内产生的所有报文段都在网络中消失,这样在下一个连接中就不会出现这种旧的连接请求报文段。
保活计时器:
客户端在于服务器建立TCP连接后,如果客户端突发意外,为避免服务器端无限制等待,服务器端采用保活计时器;服务器端每收到客户端的数据后,就重置保活计时器;若超出时间限制未收到数据,就像客户端发送探测报文段;若一连发送十个都没有客户端响应,服务器端就关闭连接。
面试怎么问
以下总结运输层面试可能会问的问题;
问题与答法均来自:
https://github.com/Snailclimb/JavaGuide/blob/master/计算机网络与数据通信/计算机网络.md#二-tcp-三次握手和四次挥手面试常客
TCP 三次握手和四次挥手
TCP、UDP 协议的区别
TCP 协议如何保证可靠传输
在浏览器中输入url地址 ->> 显示主页的过程(面试常客)