传输层中一些零碎且易忘的知识点-Toy模板网

这篇具有很好参考价值的文章主要介绍了传输层中一些零碎且易忘的知识点。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

端口号：共两个字节
- 不同类型的端口号：
  - 服务端端口号
    - 熟知端口号：0～1023
    - 登记端口号：1024～49151
  - 客户端使用端口号（短暂/临时端口号）：49152～65535
- 要记得常见应用程序的熟知端口号
  - FTP：21
  - TELNET：23
  - SMTP：25
  - DNS：53
  - TFTP：69
  - HTTP：80
  - SNMP：161
首部与伪首部：

伪首部中协议字段为6时表示TCP，为17时表示UDP
复用和分用
- 复用（针对发送主机）：从不同套接字（IP+端口号）收集数据块，并为每个数据块封装上首部信息，生成报文段，传给网络层。如UDP的复用就是指不同进程使用同一个传输层协议传送数据
- 分用（针对接收主机）：将报文段中的数据交付到正确的套接字。因此UDP协议实现分用时所依据的头部字段就是目的端口号
注意“复用分用”和“多路复用”的区别：
多路复用指一个信道同时传输多路信号，这在数据链路层就实现了
接收端收到有差错的UDP用户数据时的处理方式是：丢弃
客户-服务器领域、远程调用、实时多媒体应用适合使用UDP协议；远程登录不适合使用UDP协议
A和B建立了TCP连接，当A收到确认号为100的确认报文段时，意味着B期望下次收到的报文段序号是100，因此意味着末字节序号为99的报文段已收到
TCP将数据视为无结构有序字节流，序号（seq）是本报文段第一字节的序号，确认号（ack）是期望收到的下一个报文段的第一个字节的序号，因此TCP并不是对每一个字节都确认，而是一次确认一个报文段。即为保证数据传输的可靠性，TCP采用了对报文段确认的机制
TCP的滑动窗口协议中规定重传分组的数量最多可以等于滑动窗口的大小，分组重传的最大值也是发送方能发送数据的最大值
TCP中滑动窗口的值应设置适当
- 若设置太大，则一次会发送过多的数据，会导致网络拥挤，从而丢失分组
- 若设置太小，则会产生过多的确认报文
TCP的四种拥塞控制方法：
- 慢开始：指一开始向网络注入的报文段少，并不是指拥塞窗口cwnd的值增长速度慢
- 拥塞避免（加法增大）：并非指完全能够避免拥塞，而是指在拥塞避免阶段将cwnd值控制为按线性规律增长，使网络比较不容易出现拥塞
- 快重传：指让发送方尽早进行重传，而不是等重传计时器超时再重传。具体的，发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传
- 快恢复：发送方一旦收到3个确认，就执行快恢复算法（而非慢开始），将满开始门限ssthresh的值和拥塞窗口cwnd的值都调整为当前cwnd值的一半，并开始执行拥塞避免算法
假设客户C和服务器S已建立一个TCP连接，则从C主动向S发出FIN段时刻起，C和S进入CLOSED状态所需的时间至少为：C端为1 RTT+2 MSL；S端为 1.5 RTT。如下图，“至少”情况下，第二次挥手和第三次挥手可合并为一次
MSS：TCP最大报文段（TCP报文段的数据载荷部分）。讨论TCP的四种拥塞控制方法（慢开始、拥塞避免、快重传、快恢复）时，是以MSS的个数作为讨论问题的单位的，而不是以字节为单位（尽管TCP是面向字节流的）
TCP的四种拥塞控制方法：慢开始、拥塞避免、快重传、快恢复
UDP是面向应用报文的，TCP是面向字节流的：
发送方的TCP把应用进程交付下来的应用报文看作是一连串的无结构的字节流，且TCP并不知道这些待传输字节流的含义，仅将它们编号并存储在自己的发送缓存中。TCP根据发送策略，从发送缓存中提取一定数量的字节，构建TCP报文段并进行发送。接收方的TCP一方面从所接收到的TCP报文段中取出数据载荷并存储在接收缓存中，另一方面将接收缓存中的一些字节向上交付给应用进程。TCP不保证接收方应用进程所接收到的数据块与发送方应用进程所发出的应用层报文之间具有对应大小的关系。例如，发送方应用进程交给发送方的TCP共10个应用层报文，但接收方的TCP可能只用了4个数据块就把收到的字节流交付给了上层的应用进程。但接收方应用进程收到的字节流必须和发送方应用进程发出的字节流完全一样。因此，接收方的应用进程必须有能力识别收到的字节流，把它还原成有意义的应用层报文。
“TCP是面向字节流的”这一特点也正是流量控制、拥塞控制的基础