Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit 21bd3f6

Browse files
Update 计算机网络.md
1 parent 63652ca commit 21bd3f6

File tree

1 file changed

+11
-25
lines changed

1 file changed

+11
-25
lines changed

‎docs/network/计算机网络.md‎

Lines changed: 11 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -38,7 +38,7 @@
3838

3939
学习计算机网络时我们一般采用折中的办法,也就是中和 OSI 和 TCP/IP 的优点,采用一种只有五层协议的体系结构,这样既简洁又能将概念阐述清楚。
4040

41-
![五层协议的体系结构](https://user-gold-cdn.xitu.io/2018/7/29/164e5307471e8eba?w=633&h=344&f=png&s=164623)
41+
![五层体系结构](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019/7/五层体系结构.png)
4242

4343
结合互联网的情况,自上而下地,非常简要的介绍一下各层的作用。
4444

@@ -91,7 +91,8 @@
9191
### 1.6 总结一下
9292

9393
上面我们对计算机网络的五层体系结构有了初步的了解,下面附送一张七层体系结构图总结一下。图片来源:https://blog.csdn.net/yaopeng_2005/article/details/7064869
94-
![七层体系结构图](https://user-gold-cdn.xitu.io/2018/7/29/164e529309f0fa33?w=1120&h=1587&f=gif&s=225325)
94+
95+
![七层体系结构图](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019/7/七层体系结构图.png)
9596

9697
## 二 TCP 三次握手和四次挥手(面试常客)
9798

@@ -100,10 +101,10 @@
100101
### 2.1 TCP 三次握手漫画图解
101102

102103
如下图所示,下面的两个机器人通过3次握手确定了对方能正确接收和发送消息(图片来源:《图解HTTP》)。
103-
![TCP三次握手](https://user-gold-cdn.xitu.io/2018/5/8/1633e127396541f1?w=864&h=439&f=png&s=226095)
104+
![TCP三次握手](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019/7/三次握手.png)
104105

105106
**简单示意图:**
106-
![TCP三次握手](https://user-gold-cdn.xitu.io/2018/5/8/1633e14233d95972?w=542&h=427&f=jpeg&s=15088)
107+
![TCP三次握手](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019/7/三次握手2.png)
107108

108109
- 客户端–发送带有 SYN 标志的数据包–一次握手–服务端
109110
- 服务端–发送带有 SYN/ACK 标志的数据包–二次握手–客户端
@@ -131,7 +132,7 @@
131132

132133
双方通信无误必须是两者互相发送信息都无误。传了 SYN,证明发送方到接收方的通道没有问题,但是接收方到发送方的通道还需要 ACK 信号来进行验证。
133134

134-
![TCP四次挥手](https://user-gold-cdn.xitu.io/2018/5/8/1633e1676e2ac0a3?w=500&h=340&f=jpeg&s=13406)
135+
![TCP四次挥手](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019/7/TCP四次挥手.png)
135136

136137
断开一个 TCP 连接则需要"四次挥手":
137138

@@ -178,30 +179,18 @@ TCP 提供面向连接的服务。在传送数据之前必须先建立连接,
178179

179180
**缺点:** 信道利用率低,等待时间长
180181

181-
182182
**1) 无差错情况:**
183183

184-
![](https://user-gold-cdn.xitu.io/2018/8/16/16541fa8c3816a90?w=514&h=473&f=png&s=9924)
185-
186184
发送方发送分组,接收方在规定时间内收到,并且回复确认.发送方再次发送。
187185

188186
**2) 出现差错情况(超时重传):**
189-
![](https://user-gold-cdn.xitu.io/2018/8/16/16541faefdf249ab?w=953&h=480&f=png&s=19163)
187+
190188
停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认,就重传前面发送过的分组(认为刚才发送过的分组丢失了)。因此每发送完一个分组需要设置一个超时计时器,其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为 **自动重传请求 ARQ** 。另外在停止等待协议中若收到重复分组,就丢弃该分组,但同时还要发送确认。**连续 ARQ 协议** 可提高信道利用率。发送维持一个发送窗口,凡位于发送窗口内的分组可连续发送出去,而不需要等待对方确认。接收方一般采用累积确认,对按序到达的最后一个分组发送确认,表明到这个分组位置的所有分组都已经正确收到了。
191189

192190
**3) 确认丢失和确认迟到**
193191

194-
- **确认丢失**:确认消息在传输过程丢失
195-
![](https://user-gold-cdn.xitu.io/2018/8/16/16541fb6941a7165?w=918&h=461&f=png&s=19841)
196-
当A发送M1消息,B收到后,B向A发送了一个M1确认消息,但却在传输过程中丢失。而A并不知道,在超时计时过后,A重传M1消息,B再次收到该消息后采取以下两点措施:
197-
198-
1. 丢弃这个重复的M1消息,不向上层交付。
199-
2. 向A发送确认消息。(不会认为已经发送过了,就不再发送。A能重传,就证明B的确认消息丢失)。
200-
- **确认迟到** :确认消息在传输过程中迟到
201-
![](https://user-gold-cdn.xitu.io/2018/8/16/16541fdd85929e6b?w=899&h=450&f=png&s=23165)
202-
A发送M1消息,B收到并发送确认。在超时时间内没有收到确认消息,A重传M1消息,B仍然收到并继续发送确认消息(B收到了2份M1)。此时A收到了B第二次发送的确认消息。接着发送其他数据。过了一会,A收到了B第一次发送的对M1的确认消息(A也收到了2份确认消息)。处理如下:
203-
1. A收到重复的确认后,直接丢弃。
204-
2. B收到重复的M1后,也直接丢弃重复的M1。
192+
- **确认丢失** :确认消息在传输过程丢失。当A发送M1消息,B收到后,B向A发送了一个M1确认消息,但却在传输过程中丢失。而A并不知道,在超时计时过后,A重传M1消息,B再次收到该消息后采取以下两点措施:1. 丢弃这个重复的M1消息,不向上层交付。 2. 向A发送确认消息。(不会认为已经发送过了,就不再发送。A能重传,就证明B的确认消息丢失)。
193+
- **确认迟到** :确认消息在传输过程中迟到。A发送M1消息,B收到并发送确认。在超时时间内没有收到确认消息,A重传M1消息,B仍然收到并继续发送确认消息(B收到了2份M1)。此时A收到了B第二次发送的确认消息。接着发送其他数据。过了一会,A收到了B第一次发送的对M1的确认消息(A也收到了2份确认消息)。处理如下:1. A收到重复的确认后,直接丢弃。2. B收到重复的M1后,也直接丢弃重复的M1。
205194

206195
#### 连续ARQ协议
207196

@@ -224,12 +213,9 @@ TCP 提供面向连接的服务。在传送数据之前必须先建立连接,
224213
TCP的拥塞控制采用了四种算法,即 **慢开始****拥塞避免****快重传****快恢复**。在网络层也可以使路由器采用适当的分组丢弃策略(如主动队列管理 AQM),以减少网络拥塞的发生。
225214

226215
- **慢开始:** 慢开始算法的思路是当主机开始发送数据时,如果立即把大量数据字节注入到网络,那么可能会引起网络阻塞,因为现在还不知道网络的符合情况。经验表明,较好的方法是先探测一下,即由小到大逐渐增大发送窗口,也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1,每经过一个传播轮次,cwnd加倍。
227-
![](https://user-gold-cdn.xitu.io/2018/8/10/1652348ada2c8fd0?w=1050&h=560&f=jpeg&s=112611)
228216
- **拥塞避免:** 拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大,即每经过一个往返时间RTT就把发送放的cwnd加1.
229217
- **快重传与快恢复:**
230218
在 TCP/IP 中,快速重传和恢复(fast retransmit and recovery,FRR)是一种拥塞控制算法,它能快速恢复丢失的数据包。没有 FRR,如果数据包丢失了,TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内,没有新的或复制的数据包被发送。有了 FRR,如果接收机接收到一个不按顺序的数据段,它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认,它会假定确认件指出的数据段丢失了,并立即重传这些丢失的数据段。有了 FRR,就不会因为重传时要求的暂停被耽误。 当有单独的数据包丢失时,快速重传和恢复(FRR)能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时,它则不能很有效地工作。
231-
232-
![快重传与快恢复](https://user-gold-cdn.xitu.io/2018/8/10/165234f0303d174b?w=1174&h=648&f=png&s=109568)
233219

234220

235221
## 五 在浏览器中输入url地址 ->> 显示主页的过程(面试常客)
@@ -255,15 +241,15 @@ TCP的拥塞控制采用了四种算法,即 **慢开始** 、 **拥塞避免**
255241

256242
## 六 状态码
257243

258-
![状态码](https://user-gold-cdn.xitu.io/2018/5/8/1633e19dba27ed00?w=673&h=218&f=png&s=72968)
244+
![状态码](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019/7/状态码.png)
259245

260246

261247
## 七 各种协议与HTTP协议之间的关系
262248
一般面试官会通过这样的问题来考察你对计算机网络知识体系的理解。
263249

264250
图片来源:《图解HTTP》
265251

266-
![各种协议与HTTP协议之间的关系](https://user-gold-cdn.xitu.io/2018/5/8/1633ead316d07713?w=841&h=1193&f=png&s=609513)
252+
![各种协议与HTTP协议之间的关系](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019/7/各种协议与HTTP协议之间的关系.png)
267253

268254
## 八 HTTP长连接,短连接
269255

0 commit comments

Comments
(0)

AltStyle によって変換されたページ (->オリジナル) /