fix: fix some inappropriate descriptions in 计算机网络/Transport Layer.md.
This commit is contained in:
xUhEngwAng
@@ -9,7 +9,7 @@
|
||||
|
||||
### 进程之间的通信
|
||||
|
||||
通过IP层，数据可以从网络中另一台计算机交付到当前的计算机。这些数据必然需要某个特定的应用程序来读取，以便进行处理，显示给用户。传输层提供的就是这样_进程对进程_之间的通信。
|
||||
通过IP层，数据可以从网络中另一台计算机交付到当前的计算机。这些数据必然需要某个特定的应用程序来读取，以便进行处理，显示给用户。传输层提供的就是这样<strong>进程对进程</strong>之间的通信。
|
||||
|
||||
这样的话，发送数据的一方就不只是需要指定接收方的IP地址，还需要指定对方主机是由哪个进程来接收这些数据。
|
||||
|
||||
@@ -49,12 +49,12 @@
|
||||
|
||||
## UDP
|
||||
|
||||
话虽然像上面那样说，但是UDP就是一个叛徒。它明明知道作为一个传输层，它的主要任务应该是可靠传输，可是由于人人都有惰性，它就采用了一个怎么简单怎么来的尽最大努力交付。所以，简单说来，它的特点就体现在一个字，简单！
|
||||
话虽然像上面那样说，但是 UDP 只是采用了一个怎么简单怎么来的尽最大努力交付。所以 UDP 的特点是非常简单。
|
||||
|
||||
+ 无连接的传输。传输前不需要先建立连接
|
||||
+ 尽最大努力交付，不保证可靠交付
|
||||
+ 面向报文的。上面的应用进程交给它多大的报文要它发送，它就一股脑一起打个包就发送了。尽管报文太大会使下面IP层分片，报文太小会使得传输效率低下。简单说来就是消极怠工，让干什么就只干什么，绝对不会多做一点工作。
|
||||
+ 没有拥塞控制。(当然没有了！ 就是说即使网络已经很拥塞了，他还是继续发他的数据，这样就可能导致一些数据的丢失(缓存满了就被路由器丢掉了)。但是这样居然还有一定的好处，就是尽管数据会有丢失，但不会有太大的时延，因此对于一些实时性应用非常有用。比如像QQ这样的就是主要用UDP。
|
||||
+ 面向报文的。上面的应用进程交给它多大的报文要它发送，它就一股脑一起打个包就发送了。尽管报文太大会使下面IP层分片，报文太小会使得传输效率低下。
|
||||
+ 没有拥塞控制。即使网络已经很拥塞了，他还是继续发他的数据，这样就可能导致一些数据的丢失，因为缓存满了就被路由器丢掉了。但是这样居然还有一定的好处，就是尽管数据会有丢失，但不会有太大的时延，因此对于一些实时性应用非常有用。比如像 QQ 这样的就是主要用UDP。
|
||||
+ 支持一对一，一对多，多对一和多对多的交互通信。毕竟无连接啊
|
||||
+ 首部开销小。它都这么简单了，还需要什么首部开销？无非
|
||||
- 源端口：两字节
|
||||
@@ -66,11 +66,11 @@
|
||||
|
||||
### 概述
|
||||
|
||||
TCP就比较强了，提供的是可靠的传输。除此以外，还提供了额外的功能，像是流量控制，拥塞控制这样。堪称模范好学生好吧。所以很明显，他非常复杂...他的特点也一个字，难
|
||||
TCP就比较强了，提供的是可靠的传输。除此以外，还提供了额外的功能，像是流量控制，拥塞控制这样。所以很明显，他非常复杂...
|
||||
|
||||
+ 面向连接的传输。数据传输之前必须先建立连接。传输完数据后必须释放已经建立的连接。
|
||||
+ 只能一对一。因为面向连接啊，你只能传输给连接的另一方。
|
||||
+ 提供可靠交付的服务。通过TCP传输的数据，无差错，不丢失，不重复，并且按序到达(你听听，这还是人话吗
|
||||
+ 提供可靠交付的服务。通过TCP传输的数据，无差错，不丢失，不重复，并且按序到达
|
||||
+ 提供全双工通信。双方都有发送缓存和接受缓存，可以同时收发
|
||||
+ 面向字节流。TCP并不理解应用进程交给它的报文，而只是看做无结构的字节流。所以他可以自己决定什么时候发送多大的字节流，这样发送的时候就顺便加上流量控制和拥塞控制。只要接收方收到同样的字节流就行。
|
||||
|
||||
@@ -118,7 +118,7 @@ TCP就比较强了，提供的是可靠的传输。除此以外，还提供了
|
||||
|
||||
一个改进方法是，既然不能算，那我就不算了(?)。只要报文重传了，就不计算其RTT。但是这样的话，如果某一时刻，时延突然增大了很多，使得报文发生重传。这以后RTT时间就无法进行更新，因此报文就不断重传。
|
||||
|
||||
所以最终方案是，如果报文重传了，就不计算它的RTT，而是直接将之前的超时重传时间`RTO`加倍(真的简单粗暴)
|
||||
所以最终方案是，如果报文重传了，就不计算它的RTT，而是直接将之前的超时重传时间`RTO`加倍。
|
||||
|
||||
### TCP流量控制
|
||||
|
||||
@@ -154,7 +154,7 @@ TCP就比较强了，提供的是可靠的传输。除此以外，还提供了
|
||||
+ 只有收到对前一个报文段的确认后，才能发送后一个报文段(类似停止等待协议，但这是基于时间的发送)
|
||||
+ 当到达的数据达到发送窗口的一半或已经达到最大报文段长度(MSS)时，立即发送(基于报文大小的发送)
|
||||
|
||||
上述基于滑动窗口的流量控制还有一个叫_糊涂窗口综合征_的问题。
|
||||
上述基于滑动窗口的流量控制还有一个叫<strong>糊涂窗口综合征</strong>的问题。
|
||||
|
||||
### TCP的拥塞控制
|
||||
|
||||
|
||||
Reference in New Issue
Block a user