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