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 2019-06-05 14:12:01 +08:00 committed by GitHub
parent de1beb701f
commit 3089b0aff7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -228,8 +228,8 @@ TCP的拥塞控制采用了四种算法即 **慢开始** 、 **拥塞避免**
- **拥塞避免:** 拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大即每经过一个往返时间RTT就把发送放的cwnd加1. - **拥塞避免:** 拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大即每经过一个往返时间RTT就把发送放的cwnd加1.
- **快重传与快恢复:** - **快重传与快恢复:**
在 TCP/IP 中快速重传和恢复fast retransmit and recoveryFRR是一种拥塞控制算法它能快速恢复丢失的数据包。没有 FRR如果数据包丢失了TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内,没有新的或复制的数据包被发送。有了 FRR如果接收机接收到一个不按顺序的数据段它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认它会假定确认件指出的数据段丢失了并立即重传这些丢失的数据段。有了 FRR就不会因为重传时要求的暂停被耽误。  当有单独的数据包丢失时快速重传和恢复FRR能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时它则不能很有效地工作。 在 TCP/IP 中快速重传和恢复fast retransmit and recoveryFRR是一种拥塞控制算法它能快速恢复丢失的数据包。没有 FRR如果数据包丢失了TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内,没有新的或复制的数据包被发送。有了 FRR如果接收机接收到一个不按顺序的数据段它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认它会假定确认件指出的数据段丢失了并立即重传这些丢失的数据段。有了 FRR就不会因为重传时要求的暂停被耽误。  当有单独的数据包丢失时快速重传和恢复FRR能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时它则不能很有效地工作。
![快重传与快恢复](https://user-gold-cdn.xitu.io/2018/8/10/165234f0303d174b?w=1174&h=648&f=png&s=109568)
![快重传与快恢复](https://user-gold-cdn.xitu.io/2018/8/10/165234f0303d174b?w=1174&h=648&f=png&s=109568)
## 五 在浏览器中输入url地址 ->> 显示主页的过程(面试常客) ## 五 在浏览器中输入url地址 ->> 显示主页的过程(面试常客)