计算机网络总复习链接🔗

传输层的功能

1. 传输层提供应用进程之间（端到端）的逻辑通信。与网络层不同，应用层提供的是主机之间的通信。
2. 复用和分用：复用是指发送方不同的应用进程可以使用同一个传输层协议传送数据，分用是指接收方的传输层在剥去报文的首部后能够把这些数据正确的交付到目的应用进程。
3. 差错检测：可以对收到的报文进行差错检测（首部和数据部分），而网络层只检查IP数据报的首部，不检查数据部分是否出错。
4. 提供两种不同的传输协议，面向连接的TCP和无连接的UDP。而网络层无法同时实现两种协议，要么是提供面向连接的服务，要么只提供无连接的服务。

端口

1. 端口的作用：硬件端口是不同硬件设备进行交互的接口，而软件端口是应用层的各种协议进程与传输实体进行层间交互的一种地址。传输层使用的是软件端口。
2. 端口号：端口号长度为16bit，能够表示65536个不同的端口号，端口号只具有本地意义，即端口号只标识本计算机应用层中的各进程，在因特网中不同计算机的相同端口号是没有联系的。根据端口号范围可以将端口分为两类：
   • 服务器端使用的端口号，又分为两类：
     • 熟知端口号：0-1023
     • 登记端口号：数值为1024-49151
   • 客户端使用的端口号：数值为49152-65535
3. 套接字：端口号拼接到IP地址构成套接字Socket，Socket=（IP:端口号），它唯一标识网络中的一台主机和其上的一个应用（进程）

UDP协议

UDP数据报

• UDP在IP数据报服务商只增加了两个最基本的服务：复用和分用以及差错检测。
• UDP具有以下特点：
  1. UDP是无连接的，UDP不会引入建立连接的时延。
  2. UDP无连接状态。TCP需要在端系统中维持连接状态。
  3. 分组首部开销小，UDP仅有8B开销，而TCP有20B的首部开销。
  4. 应用层能更好的控制要发送的数据和发送时间。UDP没有拥塞控制，因此网络中的拥塞不会影响主机的发送效率。某些实时应用要求以稳定的速度发送，能容忍一些数据的丢失，但不允许有较大的时延，而UDP正好满足这些应用的需求。
  5. UDP支持一对一、一对多、多对一和多对多的交互通信。
  6. UDP不保证可靠交付，但这并不意味着应用对数据的要求是不可靠的，所有维护可靠性的工作可由用户在应用层来完成。应用开发者可根据应用的需求来灵活设计自己的可靠性机制。
  7. UDP是面向报文的。发送方UDP对应用层交下来的报文，在添加首部后就向下交付给IP层，一次性发送一个报文，既不合并也不拆分，而是保留这些报文的边界。接收方UDP对IP层交上来的UDP数据报在去除首部后就原封不动交付给上层应用进程，一次交付一个完整报文。

UDP的首部格式

UDP的首部有8B，由4个字段组成，每个字段的长度都是2B。

1. 源端口：在需要对方回信时选用，不需要时可用全0。
2. 目的端口：在终点交付报文时必须使用到。
3. 长度：包括首部和数据，最小值是8。
4. 校验和：检测UDP数据报在传输中是否有错。有错就丢弃。该字段是可选的，当源主机不想计算校验和时，则令该字段为全0。

• 如果接收方UDP发现收到的报文中的目的端口不正确（即不存在对应于端口号的应用程序），那么就丢弃该报文，并由ICMP发送“端口不可达”差错报文给发送方。

UDP校验

在计算校验和时，要在UDP数据报前增加12B的伪首部，伪首部不是UDP真正的首部（源IP地址、目的IP地址、0、17、UDP长度）。伪首部既不向下传递也不向上递交，而只是为了计算校验和。
校验和计算：

1. 填上伪首部。
2. 全0填充校验和字段。
3. 把UDP数据包视为许多16位的字串拼接起来。若UDP数据报的数据部分不是偶数个字节，则要在数据部分末尾填入一个全零字节（此字节不发送）。
4. 按照二进制反码求和。
5. 将此和的二进制反码写入到校验和字段，并发送。
   接收方校验：
6. 把收到的UDP数据报加上伪首部（如果不是偶数个字节还得加上最后那个全零字节）。
7. 按二进制反码求和，如果没有差错那么结果应该为全1，否则就表明有差错出现，接收方就应该丢弃这个UDP数据报。

TCP协议（必考）

TCP报文段

• TCP主要有以下特点：
  1. TCP是面向连接的传输层协议，TCP连接是一条逻辑链接。
  2. 每条TCP连接只能有两个端点，每条TCP连接只能是端到端的（进程对进程）。
  3. TCP提供可靠交付的服务，保证传送的数据无差错、不丢失、不重复且有序。
  4. TCP提供全双工通信。允许通信双方的应用进程在任何时候都能发送数据，为此TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。
     • 发送缓存主要存放：①发送应用程序传给发送方TCP准备发送的数据，②TCP已发送但尚未收到确认的数据。
     • 接收缓存用来暂存以下数据：①按序道道但尚未被接收应用程序接收的数据，②不按序道道的数据。
  5. TCP是面向字节流的，虽然应用程序和TCP交互是一次一个数据块，但TCP把应用程序交下来的数据仅视为一连串无结构的字节流。
• TCP报文段首部前20B是固定的，TCP首部最短是20B，后面有4N字节是根据需要而增加的选项，长度为4B的整数倍。
• TCP首部各个字段意义如下：
  1. 源端口和目的端口：各占2B。
  2. 序号。占4B，指的是本报文段所发送的数据的第一个字节的序号。
  3. 确认号。占4B，是期望收到对方下一个报文段的第一个数据字节的序号，如果为N，则表示到序号N-1为止的所有数据都已经正确收到。
  4. 数据偏移（即首部长都）。占4位，它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。
  5. 保留。占6位。
  6. 紧急位URG。URG=1时表明紧急指针字段有效。他告诉系统此报文有紧急数据，应尽快传送。URG需要和首部中紧急指针字段配合使用，即数据从第一个字节到紧急指针所指字节就是紧急数据。
  7. 确认位ACK。仅当ACK=1时确认号才有效。当ACK=0时，确认号无效。TCP规定在连接建立后所有传送的报文段都必须把ACK置1.
  8. 推送位PSH（PUSH）。接收方TCP收到PSH=1的报文段就尽快交付给接收应用进程，而不再等到整个缓存都填满了再向上交付。
  9. 复位位RST（Reset）。当RST=1时，表明TCP连接中出现严重差错，必须释放连接重新建立连接。
  10. 同步位SYN。当SYN=1时表示这是一个连接请求报文或者连接接收报文。当SYN=1，ACK=0时表示这是一个连接请求报文，对方若同意建立连接则应在响应报文中使用SYN=1，ACK=1。
  11. 终止位FIN（Finish）。用来释放一个连接，当FIN=1时，表明此报文段的发送方的数据已发送完毕，并要求释放运输连接。
  12. 窗口。占2B，指出现在允许对方发送的数据量，接收方的缓存空间是有限的，因此用窗口值作为接收方让发送方设置其发送窗口的依据。
  13. 校验和。占2B，校验和字段检测范围包括首部和数据两部分。计算校验和和UDP一样，要加上一个伪首部只不过把协议字段17改为6，其他和UDP一样。
  14. 紧急指针。占2B。紧急指针仅在URG=1时才有意义，指出在报文段中紧急数据共有多少字节。

TCP连接的建立

• TCP连接的端口为套接字，不是主机，不是IP，不是应用进程，也不是传输层协议端口。
• TCP连接建立需要经过三个步骤，通常称为三次握手。建立连接前服务器进程处于LISTEN状态，等待客户的连接请求。
  

1. 客户机TCP首先向服务器的TCP发送连接请求报文段。这个特殊报文段的首部中的同步位SYN置1，同时选择一个初始序号seq=x。TCP规定，SYN报文段不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入SYN-SENT（同步已发送）状态。
2. 服务器的TCP收到连接请求报文段后，如同意建立连接，则向客户机发回确认，并为该TCP连接分配缓存和变量。在确认报文段中，把SYN和ACK位都置1，确认号是ack=x+1，同时也为自己选择一个初始序号seq=y。注意确认报文段不能携带数据，但也要消耗一个序号。这时，TCP服务器进程进入SYN-RCVD（同步收到）状态。
3. 当客户机收到确认报文段后，还需要向服务器给出确认，并为该TCP连接分配缓存和变量。确认报文段的ACK位置1，确认号ack=y+1，序号seq=x+1。该报文段可以携带数据，若不携带数据则不消耗序号。这时TCP客户进程进入ESTABLISHED（已建立连接）状态。

• TCP建立的是全双工通信，因此通信双方的应用进程在任何时候都能发送数据。
• 服务器端资源是在第二次握手时分配的，而客户端的资源是在完成第三次握手时分配的，这就使得服务器易于受到SYN洪泛攻击。（有关洪泛攻击的部分当作科普来看着玩即可，不会考）
• SYN洪泛攻击发生在OSI第四层，这种方式利用TCP协议的特性，就是三次握手。攻击者发送TCP SYN，SYN是TCP三次握手的第一个数据包，当服务器返回ACK后，该攻击者就不对其进行再确认，那这个TCP连接就属于挂起状态，也就是所谓的半连接状态，服务器收不到再确认的话还会重复发送ACK给攻击者，这样更加会浪费服务器的资源。攻击者就对服务器发送非常大量的这种TCP连接，由于每一个都没法完成三次握手，所以在服务器上，这些TCP连接会因为挂起状态而消耗CPU和内存，最后服务器可能死机，就无法为正常用户提供服务了。
• 如何防御SYN洪泛攻击？

1. 确保网络设备有最新的安全补丁和更新，以防止已知的漏洞被利用。
2. 启用SYN Cookies技术，可以在处理TCP连接请求时对客户端进行验证，以确保它们是真实的请求。SYN Cookies 技术通过在目标服务器上生成加密的临时 TCP 连接令牌（token），来代替传统TCP 三次握手过程中的 SYN-ACK 握手过程，用于验证客户端请求的可信性。这些加密的临时令牌仅用于建立连接期间的校验，不会留存在任何存储设备中，从而保护了系统的安全。
3. 实施网络轮廓与访问控制策略，防止不必要的流量进入网络。
4. 配置网络设备以限制每个IP地址的连接数量，避免过多的连接占用大量系统资源。
5. 配置firewall防火墙规则以拦截可疑的数据包和来源不明IP地址的访问。

TCP连接的释放

1. 客户机打算关闭连接时，向服务器发送连接释放报文段，并停止发送数据，该报文段FIN置1，序号seq=u，它等于前面已传送过的数据的最后一个字节的序号加1，FIN报文段即使不携带数据，也消耗一个序号。这时，TCP客户进入FIN-WAIT-1状态。TCP是全双工的，即可以想象为一条TCP连接上有两条数据通路发送FIN的一端不能再发送数据，但对方还可以发送数据。
2. 服务器收到连接释放报文段后即发出确认，确认号ack=u+1，序号seq=v，等于它前面已传送过的数据的最后一个字节的序号加1.然后服务器进入CLOSE-WAIT状态。此时，从客户机到服务器这个方向的连接就释放了，TCP连接处于半关闭状态。但服务器若发送数据，客户机仍要接收，即从服务器到客户机这个方向的连接并未关闭。
3. 若服务器已经没有要向客户机发送的数据，就通知TCP释放连接，此时，其发出FIN=1的连接释放报文段，设该报文段的序号为w，还需重复上次已发送的确认号ack=u+1.这时服务器进入LAST-ACK。
4. 客户机收到连接释放报文段后，必须发出确认。把确认报文段中的ACK置1，确认号ack=w+1，序号seq=u+1.此时TCP连接还未释放，必须经过实践等待计时器设置的时间2MSL（最长报文段寿命）后，客户机才进入CLOSED状态。

TCP的可靠传输

TCP的流量控制

零窗口探测报文段

TCP的拥塞控制

慢开始和拥塞控制

快重传和快恢复

TCP和UDP对比

1. TCP面向连接，UDP无连接。面向连接服务就是在通信双方进行通信之前，必须先建立连接，在通信过程中整个连接的情况一直被实时的监控和管理。通信结束后，应该释放这个链接。无连接服务是指两个实体之间不需要提前建立连接，需要通信时，直接将信息发送到“网络中”，让该信息的传递在网上尽力而为的往目的地传送。
2. 发送报文采用的方式不同。UDP报文的长度由发送应用进程决定，而TCP报文的长度则根据接收方给出的窗口值和当前的网络拥塞成都来决定。如果应用进程传送到TCP缓存的数据块太长，TCP就把它划分得短一些再传送。如果太短TCP也会等到积累足够多的字节后再构成报文段发送出去。

本章问题汇集

1. MSS设置得太大或太小会有什么影响？
2. 为何不采用“三次握手”释放连接，且发送最后一次握手报文后要等待2MSL得时间呢？
   • 保证A发送的最后一个确认报文段能够到达B。如果A不等待2MSL，若A返回的最后确认报文段丢失，则B不能进入正常关闭状态，而A此时已经关闭，也不可能再重传。
   • 防止出现“已失效的连接请求报文段”。A在发送最后一个确认报文段后，再经过2MSL可保证本链接持续的时间内产生的所有报文段从网络中消失。
3. 如何判定此确认报文段是对原来得报文段的确认，还是对重传的报文段的确认？
4. TCP使用的是GBN还是选择重传？
5. 为什么超时时间发生时cwnd被置为1，而收到3个冗余ACK时cwnd减半？
6. 为什么不采用“两次握手”建立连接呢？
   • 这主要是为了防止两次握手情况下已失效的连接请求报文段突然又传送到服务器而产生错误。
   • 考虑下面这种情况。客户A向服务器B发出TCP连接请求，第一个连接请求报文在网络的某个结点长时间滞留，A超时后认为报文丢失，于是再重传一次连接请求，B收到后建立连接。数据传输完毕后双方断开连接。而此时，前一个滞留在网络中的连接请求到达服务器B，而B认为A又发来连接请求，此时若使用“三次握手"，则B向A返回确认报文段，由于是一个失效的请求，因此A不予理睬，建立连接失败。若采用的是“两次握手”，则这种情况下B认为传输连接已经建立，并一直等待A传输数据，而A此时并无连接请求，因此不予理睬，这样就造成了B的资源白白浪费。
7. 是否TCP和UDP都需要计算往返时间RTT？
8. 为什么TCP在建立连接时不能每次都选择相同的、固定的初始序号？