网络7层架构与TCP与UDP

一、网络的7层架构

1、咋记住？

2、咋理解？

1. 数据利用比特流（010101）通过网线传输到另外一个设备，属于物理层
2. 必须保证传输比特流的准确性，于是有纠错功能的数据链路层。
3. A的数据要传输到C，中间要经过B，那么就需要IP寻址，属于网络层
4. A机器给C机器发消息，但是消息很大，需要分多个包传送过去，这属于传输层
   1. tcp：可靠、面向链接、传输效率低（拥塞控制、超时丢失重传）
   2. udp：不可靠、无连接、传输效率高（丢失、重复、乱序）
5. 我就想和你说两句话，不想去调用TCP打包拆包和路由寻址这些，那么自动打包拆包的功能，就是会话层。（用于建立和管理应用程序之间的通信）
6. 我用Mac电脑给你的windows电脑发消息，为了解决俩不同系统之间的通信问题，就有了表现层
7. 基于上面6层，我们开发的各种应用，叫做应用层
   1. 浏览器：通过定义 http 超文本传输协议；
   2. FTP服务：FTP 文件传输协议；
   3. 邮箱：SMTP，简单邮件传输协议；
   4. POP3：邮局协议第3版；
   5. telnet：TCP/IP终端仿真协议；
   6. Finger：用户信息协议；
   7. IMAP4：因特网信息访问协议第4版。
   8. lpr unix ：远程打印协议。

二、面试常问

1、TCP与UDP的区别

TCP（传输控制协议）和UDP（用户数据报协议）是两种常见的传输层协议，用于在计算机网络中传输数据。它们之间存在以下几个主要区别：

1. 连接导向 vs. 无连接：

   1. TCP是面向连接的协议，通过建立可靠的连接来传输数据，确保数据的有序性、完整性和可靠性。
   2. UDP是无连接的协议，每个数据报都是独立的，没有建立和维护连接的开销，但也不保证数据的可靠性和顺序性。

2. 可靠性：

   1. TCP提供可靠的数据传输，通过确认机制、超时重传、丢失数据的重传等来确保数据的可靠性。

   2. UDP不提供可靠性保证，数据报可能丢失、重复或乱序，应用程序需要自行处理这些问题。

3. 数据量和效率：

   1. TCP在数据传输过程中会进行拥塞控制和流量控制，以适应网络的状况，这使得它在传输大量数据或要求高可靠性的场景下更为适用。

   2. UDP没有拥塞控制和流量控制的机制，传输效率较高，适用于实时性要求较高的应用，如视频流和音频流。

4. 头部开销：

   1. TCP的头部开销相对较大，包含序列号、确认号、窗口大小等字段，这些用于实现可靠性的机制增加了额外的开销。

   2. UDP的头部开销相对较小，只包含基本的源端口、目标端口、长度和校验和字段。

综上所述，TCP适用于对数据传输的可靠性和有序性要求较高的场景，如文件传输、网页浏览等。UDP适用于实时性要求较高、对传输可靠性要求不高的场景，如实时游戏、视频通话等。选择使用哪种协议取决于具体应用的需求和对数据传输特性的权衡。

2、拥塞控制

1、拥塞控制的目的和代价

拥塞控制目的：防止过多的数据注入到网络中，避免网络中的路由器或链路过载，所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

拥塞控制代价：需要获得网络内部流量分布的信息。在实施拥塞控制之前，还需要在结点之间交换信息和各种命令，以便选择控制的策略和实施控制。这样就产生了额外的开销。

2、拥塞控制的几种方法

慢开始

探测式的开始，TCP开始发送报文段时先设置cwnd=1，使得发送方在开始时只发送一个报文段（目的是试探一下网络的拥塞情况），每次翻倍窗口大小

慢开始算法只是在TCP连接建立时和网络出现超时时才使用。

拥塞避免

 为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh(Slow Start threshold，慢启动阈值)状态变量（如何设置ssthresh）。慢开始门限ssthresh的用法如下：

    当 cwnd < ssthresh 时，使用上述的慢开始算法。

    当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。

    当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法。

“拥塞避免”是说在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。

快恢复

与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口cwnd现在不设置为1），而是把cwnd值设置为 慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。这方法叫做快恢复！

快重传

快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时才进行捎带确认。

1. 接收方收到了M1和M2后都分别发出了确认。
2. 现在假定接收方没有收到M3但接着收到了M4。显然，接收方不能确认M4，因为M4是收到的失序报文段。
3. 根据可靠传输原理，接收方可以什么都不做，也可以在适当时机发送一次对M2的确认。但按照快重传算法的规定，接收方应及时发送对M2的重复确认，这样做可以让发送方及早知道报文段M3没有到达接收方。
4. 发送方接着发送了M5和M6。接收方收到这两个报文后，也还要再次发出对M2的重复确认。这样，发送方共收到了接收方的四个对M2的确认，其中后三个都是重复确认。
5. 快重传算法还规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段M3，而不必继续等待M3设置的重传计时器到期。

3、 TCP 的三次握手

1. 第一次握手：client端发送 SYN=1 ，seq = x 给Server端 （SYN=1，这个标志位表示请求建立连接）client端状态变成 SYN_SENT
2. 第二次握手：server端发送 SYN=1，ACK=1，seq=y, ack=x+1 （SYN=1，ACK=1，这个标志位是为了告诉Client端我Server端已经准备好了），server端状态变成 SYN_RCD
3. 第三次握手：client端发送 ACK=1，seq=x+1,ack=y+1（ACK=1，这个标志位表示已经收到SYN的数据包）此时client变成 Established 状态
4. Server端收到后，变成 Established 状态

3次握手的目的

1. 第一次握手后确认client端的发送能力
2. 第二次握手后确认Server端的发送能力和接收能力
3. 第三次握手后确认了client端的接收能力

为什么握手2次不行？

2次握手没法确认client端的接收能力。

假如只有2次握手就建立链接

1. 当 Client 发送 SYN(seq=1)给Server（由于网络问题，卡在半路了，没发送到Server）
2. Client一直没收到，觉得丢了包，重新发送SYN(seq=2)给Server
3. Server收到SYN(seq=2，发送SYN-ACK 给 Client （Server 准备好了）
4. Server和Client建立链接，通信
5. SYN(seq=1) 复活了，不卡了，又发给了Server，Server收到了
6. Server收到SYN(seq=1），发送SYN-ACK 给 Client （Server 准备好了）
7. Server和Client建立链接，不通信（一直空闲着，不发东西，浪费了）

啥是半链接队列？啥是全链接队列？

1. 走完3次握手的，放全连接队列
2. 走完2次握手的，放半链接队列。如果一直没收到Client的第三次确认，Server会一直发送SYN-ACK，如果超过SYN-ACK 重传次数，那么会从半链接队列中剔除。 

ISN(Initial Sequence Number)是固定的吗

不是，如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

三次握手可以携带数据吗？

• 第一次第二次不可以，可以的话，Client 就带大量数据去攻击你这个 Server
• 第三次可以，但是也不建议（TCP协议的设计初衷是在建立连接后再开始数据的传输，这有助于确保连接的稳定性和可靠性。）

Sync攻击是什么？

1. SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，
2. Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时。
3. 这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。

检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。

在 Linux/Unix 上可以使用系统自带的 netstats 命令来检测 SYN 攻击。

netstat -n -p TCP | grep SYN_RECV

常见的防御 SYN 攻击的方法有如下几种：

• 缩短超时（SYN Timeout）时间
• 增加最大半连接数
• 过滤网关防护
• SYN cookies技术

4、 TCP 的四次挥手

1. Client 发给Server说 “离婚吧” 
2. Server回复“离就离”
3. Server在家里把Client的东西都丢掉。（Server需要处理Client的数据，可能还在处理数据当中，处理完，发送完数据给Client之后，才主动去断开链接）
4. Server发给 serverFinMsg = client “离婚协议签字吧”
5. Client 回复 clientAckMsg = ”签完了，离“
6. Client 等了 2MSL 再出国了（如果由于clientAckMsg 丢失了，那么 Server端可能会重发serverFinMsg，所以等待2MSL的目的，就是为了让 Server 可以重发，假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。）

MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。