1
0
mirror of https://github.com/Snailclimb/JavaGuide synced 2025-06-20 22:17:09 +08:00

Update 计算机网络.md

This commit is contained in:
Snailclimb 2018-08-16 17:14:11 +08:00 committed by GitHub
parent 41f2867df2
commit 772e87e71b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -37,13 +37,11 @@
<!-- /MarkdownTOC -->
相对与上一个版本的计算机网路面试知识总结,这个版本增加了 “TCP协议如何保证可靠传输”包括超时重传、停止等待协议、滑动窗口、流量控制、拥塞控制等内容并且对一些已有内容做了补充。
## 一 OSI与TCP/IP各层的结构与功能,都有哪些协议
OSI 的七层体系结构概念清楚理论也很完整但是它比较复杂而且不实用。在这里顺带提一下之前一直被一些大公司甚至一些国家政府支持的OSI失败的原因
1. OSI 的专家缺乏实际经验,他们在完成 OSI 标准时缺乏商业驱动力
2. OSI 的协议实现起来过分复杂,而且运行效率很低
3. OSI 制定标准的周期太长,因而使得按 OSI 标准生产的设备无法及时进入市场20世纪90年代初期虽然整套的 OSI 国际标准都已经制定出来,但基于 TCP/IP 的互联网已经抢先在全球相当大的范围成功运行了)
4. OSI 的层次划分不太合理,有些功能在多个层次中重复出现
### 五层协议的体系结构
@ -180,13 +178,12 @@ TCP 提供面向连接的服务。在传送数据之前必须先建立连接,
## 四 TCP 协议如何保证可靠传输
1. 应用数据被分割成 TCP 认为最适合发送的数据块。
2. **超时重传:** 当 TCP 发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段。
3. TCP 给发送的每一个包进行编号,接收方对数据包进行排序,把有序数据传送给应用层。
4. **校验和:** TCP 将保持它首部和数据的检验和。这是一个端到端的检验和目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错TCP 将丢弃这个报文段和不确认收到此报文段。
5. TCP 的接收端会丢弃重复的数据。
6. **流量控制:** TCP 连接的每一方都有固定大小的缓冲空间TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据能提示发送方降低发送的速率防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 TCP 利用滑动窗口实现流量控制)
7. **拥塞控制:** 当网络拥塞时,减少数据的发送。
8. **停止等待协议** 也是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认。在收到确认后再发下一个分组。
2. TCP 给发送的每一个包进行编号,接收方对数据包进行排序,把有序数据传送给应用层。
3. **校验和:** TCP 将保持它首部和数据的检验和。这是一个端到端的检验和目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错TCP 将丢弃这个报文段和不确认收到此报文段。
4. TCP 的接收端会丢弃重复的数据。
5. **流量控制:** TCP 连接的每一方都有固定大小的缓冲空间TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据能提示发送方降低发送的速率防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 TCP 利用滑动窗口实现流量控制)
6. **拥塞控制:** 当网络拥塞时,减少数据的发送。
7. **停止等待协议** 也是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认。在收到确认后再发下一个分组。 **超时重传:** 当 TCP 发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段。
@ -196,17 +193,27 @@ TCP 提供面向连接的服务。在传送数据之前必须先建立连接,
**1) 无差错情况:**
![](https://user-gold-cdn.xitu.io/2018/8/16/16541fa8c3816a90?w=514&h=473&f=png&s=9924)
发送方发送分组,接收方在规定时间内收到,并且回复确认.发送方再次发送。
**2) 出现差错情况(超时重传):**
停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认就重传前面发送过的分组认为刚才发送过的分组丢失了。因此每发送完一个分组需要设置一个超时计时器其重转时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为自动重传请求ARQ。另外在停止等待协议中若收到重复分组就丢弃该分组但同时还要发送确认。连续ARQ协议可提高信道利用率。发送维持一个发送窗口凡位于发送窗口内的分组可连续发送出去而不需要等待对方确认。接收方一般采用累积确认对按序到达的最后一个分组发送确认表明到这个分组位置的所有分组都已经正确收到了。
![](https://user-gold-cdn.xitu.io/2018/8/16/16541faefdf249ab?w=953&h=480&f=png&s=19163)
停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认,就重传前面发送过的分组(认为刚才发送过的分组丢失了)。因此每发送完一个分组需要设置一个超时计时器,其重转时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为 **自动重传请求 ARQ** 。另外在停止等待协议中若收到重复分组,就丢弃该分组,但同时还要发送确认。**连续 ARQ 协议** 可提高信道利用率。发送维持一个发送窗口,凡位于发送窗口内的分组可连续发送出去,而不需要等待对方确认。接收方一般采用累积确认,对按序到达的最后一个分组发送确认,表明到这个分组位置的所有分组都已经正确收到了。
**3) 确认丢失和确认迟到**
- 确认丢失:确认消息在传输过程丢失
- 确认迟到 :确认消息在传输过程中迟到
- **确认丢失**:确认消息在传输过程丢失
![](https://user-gold-cdn.xitu.io/2018/8/16/16541fb6941a7165?w=918&h=461&f=png&s=19841)
当A发送M1消息B收到后B向A发送了一个M1确认消息但却在传输过程中丢失。而A并不知道在超时计时过后A重传M1消息B再次收到该消息后采取以下两点措施
1. 丢弃这个重复的M1消息不向上层交付。
2. 向A发送确认消息。不会认为已经发送过了就不再发送。A能重传就证明B的确认消息丢失
- **确认迟到** :确认消息在传输过程中迟到
![](https://user-gold-cdn.xitu.io/2018/8/16/16541fdd85929e6b?w=899&h=450&f=png&s=23165)
A发送M1消息B收到并发送确认。在超时时间内没有收到确认消息A重传M1消息B仍然收到并继续发送确认消息B收到了2份M1。此时A收到了B第二次发送的确认消息。接着发送其他数据。过了一会A收到了B第一次发送的对M1的确认消息A也收到了2份确认消息。处理如下
1. A收到重复的确认后直接丢弃。
2. B收到重复的M1后也直接丢弃重复的M1。
### 自动重传请求 ARQ 协议
停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认就重传前面发送过的分组认为刚才发送过的分组丢失了。因此每发送完一个分组需要设置一个超时计时器其重转时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为自动重传请求ARQ。
@ -214,6 +221,7 @@ TCP 提供面向连接的服务。在传送数据之前必须先建立连接,
**优点:** 简单
**缺点:** 信道利用率低
### 连续ARQ协议
连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口,凡位于发送窗口内的分组可以连续发送出去,而不需要等待对方确认。接收方一般采用累计确认,对按序到达的最后一个分组发送确认,表明到这个分组为止的所有分组都已经正确收到了。
@ -309,5 +317,10 @@ Connection:keep-alive
[https://blog.csdn.net/zixiaomuwu/article/details/60965466](https://blog.csdn.net/zixiaomuwu/article/details/60965466)
[https://blog.csdn.net/turn__back/article/details/73743641](https://blog.csdn.net/turn__back/article/details/73743641)