计算机网络 – 运输层
运输层协议概述
进程之间的通信
什么是运输层？
网络层是解决主机与主机之间的通信，例如我的手机和你的手机之间的数据连通。但是手机中有微信，qq，王者荣耀，你一边更新王者荣耀一遍发微信，你的手机同时接收的数据包，怎么知道这些包是微信的还是王者的呢？这就是运输层做的事情：提供进程之间的通信。
和网络层以及应用层的关系？
运输层是提供一条进程之间的逻辑线路，让进程之间去通信，是比网络层更上层的协议。在路由转发中只涉及到网络层。同时运输层也是用户感知的最底层，他是直接和应用层进行连接。
运输层两个重要协议
概述
两个比较重要的协议。但是要注意和网络层的协议区分开。这里的协议指的是端对端的，是应用和主机端口之间的通信协议，而不是在路由转发中的协议。
UDP
用户数据报协议。无连接而且不可靠，因为受到数据报不需要回复。但是优点是开销小。
TCP
传输控制协议。面向连接且可靠的，但是缺点是开销比较大。而且连接的特性决定了不能进行广播和多播。
运输层的端口
什么是端口？
这个其实很好理解。因为运输层是应用程序和主机之间的逻辑通信，所以每个应用程序应该有一个标识，就像IP地址一样，不然怎么知道数据报给哪个应用呢。所以主机拿到数据报，解析一下端口号，例如80，然后就把数据给80这个端口，然后使用这个端口的应用程序就可以拿到数据了。但是有一个点是要注意的：端口是固定的但是应用程序是动态的，所以也就保证了应用程序不断切换，例如后台杀死重建啊什么的，但是依然可以接收到数据。只要使用同一个端口即可。
运输层端口和链路层的端口有什么区别？
运输层的端口是只有本都意义的，在互联网上没有任何意义。而链路层的路由器上面的端口是硬件端口，是不同设备之间的连接。而运输层的端口只是为了标识应用程序。
两大类端口
- 服务端使用的端口：服务端嘛，就是要稳定，不然一直换端口别人就受不了了。所以服务端的端口特点就是稳定，数值也比较少。
- 客户端的端口：数值比较大，但是不稳定，所以数量多。
用户数据报协议UDP
概述
UDP有什么作用：
UDP十分简单。我们知道，应用程序把数据报给到传输层，而UDP只是吧应用程序给的数据报加个头部就给网络层去转发了。头部主要是标记源端口和目的端口，以及检验正确性。
UDP的特点：
- 他是不可靠的。因为只是把数据加个头就发过去，也没有错误重发什么的。所以只是尽量交付，而不是可靠交付。
- UDP是无连接的。这个从他的工作原理可以看出来。
- UDP是面向报文的。UDP主要就是处理报文然后给网络层去转发。
- UDP没有拥塞控制。因为没有重发，也就不需要拥塞控制了。
但是
- UDP开销比较小。因为没有花里胡哨的工作。
- UDP的速度比较快，不用去创建连接直接就可以用了。
- UDP支持一对多或者多对多。
UDP头部
- 组成：三部分：源端口目的端口，长度和校验码
- 伪头部：用于创建检验码用的，伪头部主要是源IP地址，目的IP地址，协议字段值以及UDP的长度。
传输控制协议TCP概述
什么是TCP
这里只简单讲一下关于TCP的一些特点，具体的实现原理后面还有好多好多节去学习。简单来说，TCP是一个运输层的协议，他是面向连接的，和UDP不一样。TCP是建立一个连接，然后源源不断地发送数据过去。要注意的是这个连接是虚拟的，不是真实的物理连接。
TCP的特点
- 他是面向连接的
- 他是点对点的，不能一对多或者多对多等
- 他可以提供可靠交付
- 提供全双工通信（两边都可以互发信息）
- 面向字节流
什么是面向字节流
这个是TCP工作原理的重点，虽然不难，但是一定要懂。
TCP不是像UDP那样从用户那里拿数据报然后一个个发送，TCP是把这些数据看成流，在缓冲区合成一整块，然后根据网络状况，分割后加上TCP头部发送。所以说TCP是面向字节流的，因为他没有数据包的概念，用户的数据都看成流。这样的好处是TCP可以根据网络情况进行恰当地切割，防止拥塞。
TCP的连接
- TCP不是和UDP一样用端口作为点对象，而是使用socket也就是套接字为端点。套接字是什么？这个也很好理解，就是 IP+端口号。这个就可以唯一标识一个TCP连接了。
- TCP的连接是由软件所提供的一种抽象，不是真正真正真正的连接。
可靠传输的工作原理
怎样才是可靠的？
前面讲到TCP是可靠的，但是为什么TCP是可靠的？原理是什么？这一小节就比较详细地展开。这里要讲一个点，都说可靠可靠，那到底满足什么样的条件才是可靠的？
- 在网络传输的过程中不会出现数据的损坏或者丢失。
- 无论发送方用怎么样的速率去传输，接收方始终可以一直接受。
满足上述两个条件就可以实现可靠运输了。但是这两个条件和让你拿着一把刀去抢劫银行一样，看似好像很微妙，事实上就是吃太多作业太少成天幻想。所以我们要做的就是如何用协议去实现这样的特性，把不可靠的网络环境，实现可靠的数据传输。
停止等待协议
是什么？
- TCP对应用程序来的数据缓存后进行切割后，分成一个个数据报进行转发，每一个数据报转发给对方后就停下来，对方收到后就发送ACK告诉自己收到了，这个时候就可以发送第二个了。
- 如果发送的数据损坏了，或者数据在传输的时候人间蒸发了，这个时候对方什么也不做。自己就会等，等到一点时间没回复再继续发送一次，这就是超时重传。
- 如果对方给自己的确认ACK丢失或者迟到了了怎么办？自己还是按照超时重传再发一份，如果收到重复的数据就丢弃就行。对方收到重复的数据包也是直接丢弃。
- 当网络情况不好的时候，那么就会一直重发，达到一定的次数就说明当前网络不可用，停止发送。
自动重传请求：上述步骤自动完成就是ARQ自动重传请求。ARQ实现了在不可靠的网络上进行可靠的数据传输。
缺点
信道利用率很低。每次都要等，特别是网络状况不好的时候，效率会变得极低。
连续ARQ协议
为什么有这个协议？
我们可以发现就是前面的停止等待协议效率太慢了，傻傻的。一个发送出去了，没收到回复就是什么都不做，干等，所以我们可以改善这个情况。这里就要引入一个概念：流水线传输。不断地一个个发送，不用去等待回复后才可以继续发送。
如何实现
- 在上文的停止等待协议的基础上，不进行等待，不断地进行发送，用一个滑动窗口来记录。当收到对方的ACK的时候就把窗口往前移动一点。例如有123456789 共九个包，现在发送了1234，这个时候窗口就是1234，这个时候收到了数据包1 的ACK，那么窗口就变成234，以此类推。
- 接收方主要是采用累积确认的方式，只发送按序的最后一个确认。例如现在发了12345共五个包过去，然后第4个炸了，那么接受方只返回到第三的ACK，而45就会进行超时重传。好处是不用一直发送确认ACK，缺点是没办法实时监控每个包的发送情况。
- 如果发生错误，上文讲到会回退到45重传，这就是G-back-N。接收方只返回按序正确的最后一个ACK，剩下的就等待超时重传。缺点是当网络不好的时候就是一个灾难，会一直回退，导致效率极低。
TCP可靠传输小结
现在我们来小结一下如何实现可靠传输。
- TCP协议通过把用户要传输的数据当成流输入在缓存区后，按照窗口以及网络情况等适当切割并标上序号，分别发送。
- 接收端也有一个缓存区，把接收到的包都放在缓存区中，进行校对。
- 发送采用连续ARQ协议，不断发送，接受方只返回到损坏包前的序号的ACK，发送端要重传该序号后的所有包。
- 发送端和接收端都有类似的窗口来记录传输结果，保证所有包都完整送达。按照序号来保证传输的可靠传输而不是字节。所以TCP都是基于序号而不是字节。
- 因为网络情况的复杂性，所以超时重传的时间要估算比较合理。
TCP靠着连接，然后把数据分包不断重传直到全部完整发送完毕，实现了在不可靠的网络环境中，进行可靠的数据传输。
TCP 报文段的首部格式
头部各字段的含义
这一小节的内容比较枯燥，而且涉及的概念比较多。有了解过http报文的可能知道头部有很多的参数，每个参数都有独特的意义，所以还是要过一遍。然后难懂一点的字段的解释我会分开讲一下。
先上一个图：
| 头部参数 | 字节数 | 作用 |
|---|---|---|
| 源端口和目的端口字段 | 各占两字节 | 端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。 |
| 序号字段 | 4 字节 | TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。 |
| 确认号字段 | 4字节 | 是期望收到对方的下一个报文段的数据的第一个字节的序号。 |
| 数据偏移（即首部长度） | 4位 | 指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。“数据偏移”的单位是 32 位字（以 4 字节为计算单位） |
| 保留字段 | 6位 | 保留为今后使用，但目前应置为 0 |
| 紧急 URG | 1位 | 当 URG =1 时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据) |
| 确认 ACK | 1位 | 只有当 ACK=1 时确认号字段才有效。当 ACK = 0 时，确认号无效 |
| 推送 PSH (PuSH | 1位 | 接收 TCP 收到 PSH = 1 的报文段，就尽快地交付接收应用进程，而不再等到整个缓存都填满了后再向上交付。 |
| 复位 RST (ReSeT) | 1位 | 当 RST =1 时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。 |
| 同步 SYN | 1位 | 同步 SYN = 1 表示这是一个连接请求或连接接受报文。 |
| 终止 FIN (FINish) | 1位 | 用来释放一个连接。FIN = 1 表明此报文段的发送端的数据已发送完毕，并要求释放运输连接 |
| 窗口字段 | 2字节 | 用来让对方设置发送窗口的依据，单位为字节。 |
| 检验和 | 2字节 | 检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部。 |
| 紧急指针字段 | 2字节 | 指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面） |
| 选项字段 | 长度不定 | TCP 最初只规定了一种选项，即最大报文段长度 MSS。MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。”（这里他的概念是不正确的，MSS说是最大报文段长度，但实际上指的是数据段而不是整个报文段） |
| 填充字段 | 不定 | 这是为了使整个首部长度是 4 字节的整数倍。 |
选项字段中包含以下其他选项：
| 选项 | 作用 |
|---|---|
| 窗口扩大选项 | 占 3 字节，其中有一个字节表示移位值 S。新的窗口值等于 TCP 首部中的窗口位数增大到 (16 + S)，相当于把窗口值向左移动 S 位后获得实际的窗口大小 |
| 时间戳选项 | 占 10 字节，其中最主要的字段时间戳值字段（4 字节）和时间戳回送回答字段（4 字节） |
| 选择确认选项 | 接收方收到了和前面的字节流不连续的两个字节块。 |
| 如果这些字节的序号都在接收窗口之内，那么接收方就先收下这些数据，但要把这些信息准确地告诉发送方，使发送方不要再重复发送这些已收到的数据 |
重点难懂字段的解析
序号，确认号，窗口值
这几个是关系比较大的。首先我们知道tcp报是有序号的，第一个序号是指发送端发送的报文是从哪个开始，确认号是接受端返回给发送端告诉他下一个应该从哪开始。例如发送了1234，那么序号就是1，确认号就是5。窗口值指的是接收端缓冲区的大小。告诉对方我这里剩下多少缓冲内存了，你不要发太多我缓冲不下来。这里序号的单位是字节。每一个字节遍一个序号
选项字段
选项字段的长度是不定的，看要发送什么数据。根据需要改变长度。
TCP可靠传输的实现
上面我们已经讲到他的原理，这里更加详细地陈述如何实现可靠传输。
以字节为单位的滑动窗口
经过上面原理的讲述已经可以大概了解这个窗口的实现。可以先跳到前面看一下。这里说一些重点。
缓存区
发送缓存用来暂时存放：
发送应用程序传送给发送方 TCP 准备发送的数据；
TCP 已发送出但尚未收到确认的数据。接收缓存用来暂时存放：
按序到达的、但尚未被接收应用程序读取的数据；
不按序到达的数据。
实现过程
发送端的构造窗口
根据 B 给出的窗口值，A 构造出自己的发送窗口。
发送窗口表示：在没有收到 B 的确认的情况下，A 可以连续把窗口内的数据都发送出去。
发送窗口里面的序号表示允许发送的序号。
显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率。
过程
发送端
应用程序把需要发送的数据放到tcp发送缓存区中
发送端会根据接收端的窗口大小不断发送包
已经确认收到的，窗口后沿会往前走，没有收到确认就会一直等待，超时重传，直到收到确认。
后沿往前走，窗口前沿也会往前走直到全部发送完成
接收端
- 接收端接收到数据就会放到缓存区中
- 序号连续的表示数据完好，然后窗口后沿往前走，等待数据被应用程序读取。
- 遇到丢失的数据包，会发送确认让发送端重新发送。
- 窗口中包含未发送确认但是已经收到的包（也包含尚未接受到的包）
下面看个图片方便理解
注意的点
- 第一，A 的发送窗口并不总是和 B 的接收窗口一样大（因为有一定的时间滞后）。
- 第二，TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
- 第三，TCP 要求接收方必须有累积确认的功能，这样可以减小传输开销。
- 接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。
但请注意两点：- 第一，接收方不应过分推迟发送确认，否则会导致发送方不必要的重传，这反而浪费了网络的资源。。
- 第二，捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。
超时重传时间的选择
为什么很重要
这个点是前面我们没有讲的但是非常重要的点。因为这个时间要把握好。如果把握不好会有什么问题：
- 时间太长：空闲时间太长，效率差
- 时间太短：频繁重发，浪费资源。
受什么因素影响
网络的情况是十分复杂的，所以导致网络传输的情况变得十分复杂，所以这个时间也很难去确定，所以必须采用合适的算法来确定这个时间。
算法：加权平均往返时间
加权平均往返时间RTTs = （1-a）*旧的往返时间+a*新的往返时间
这里一开始RTT采用第一次测得的往返时间，并以此为基础进行计算。这里的a是一个系数，RFC规定是 0.125.
这样就可以不断地更新往返时间，得到网络的情况，可以更好地确定超时重传时间。
超时重传时间RTO算法
RTO = RTTs+4*RTTd
RTTd = (1-b)*旧的RTTd+b*|RTTs-新的样本RTT|
- RTTd是RTT 的偏差的加权平均值，一般来说第一次取RTT的一半
- b的推荐值是0.25
- 这个算法是根据网络波动来确定重传的时间的，如果网络稳定，则重传时间就接近往返时间，网络波动越大，则超时重传的时间约大
Karn算法
这里还有一个问题就是：如果重传了，然后接收到一个ack，那么这个ack是重传前的那个包的，还是重传后这个包的？很难确定对吧。所以这里就诞生了这个算法。
最初这个算法是直接丢弃重传包样本，但是这样肯定不行的，会让算法不准确。所以修正后是RTO = y*旧的RTO。这里的y一般是2.这样当发生重传的时候，就会把该样本的信息记录下来了。
选择确认SACK
前面我们讲到累积确认的时候讲到：当收到错误或者漏包的时候，只会发送这个错误的包前的确认完好的ack，剩下的都要重传。例如收到12678。那么会发送确认号为3的ack，这样的话，678也要重传一次，就浪费资源了。所以我们可以告诉发送端说我已经收到了什么，只需要把缺的发送给我就行。这个时候就可以用到选择确认SACK。
上文讲头部字段的时候讲到这个选项，他的最大值是40字节。每一个确认的字段，例如上面的12678例子。12段需要一个左边界1和右边界2,678需要左边界6，右边界8.所以每个要告诉发送端的已经完好的字段都需要两个边界：左边界和右边界。一个边界需要4个字节，所以最多只能告诉接收端4个完好的字段。
TCP可靠传输小结
TCP通过滑动窗口以及超时重传算法来使得发送的数据变得非常可靠，效率也比较高。另外再通过选择确认SACK进一步加强了性能。这三个是需要掌握的点，特别是超时重传时间的算法和滑动窗口的原理。
TCP的流量控制
什么是流量控制？为什么要进行流量控制？
流量控制这个很好理解，就是控制管道中传输的数据量。控制流量是为了不让管道发生拥塞，从而来提高效率。另一方面，如果发送端的速度太快，接收端可能会来不及接受就会导致数据的丢失。
利用滑动窗口来提高效率
前面我们讲到tcp头部有一个窗口值，可以用来记录接收方还有多少的缓存。tcp主要就是利用这一点来保证有足够的缓存，而不会无法接收。当接收方的的缓存满了之后，ack’中的窗口值就是0。当接收方中的缓存多了之后，就会发送一个数据报告知发送端我有内存了，可以发送数据过来了。
这里有一个问题：如果接收端告知可以发送数据的tcp报丢失了怎么办？持续计时器。
当发送端收到窗口值为0的tcp报的时候，就会开始计时器，计时器时间到了就会发送一个试探报，数据只有一个字节。如果还是缓存满，就重新开始计算计时器。
提高传输效率
相关机制
- 发送的数据长度不能太短也不能太长，参考MSS。
- 按照接收端的要求发送push报文
- 持续计时器到了，就要发送数据报，不能干等待
糊涂窗口综合症和Nagle算法
听起来好高大上，其实很简单。当缓存区还没有数据的时候，这个时候收到一个字节是不是就会马上发出去了？这样就不符合上面说的效率限制了。然后接收端，如果是满的，然后应用程序读取了一个字节，是不是马上就通知发送端可以发送一个字节的数据了。这样都是会让网络效率降低。所以正确的方法就是：等。等到一定长度后，再进行发送。这也就是Nagle算法。
TCP的拥塞控制
拥塞原理
什么是拥塞？
什么是拥塞？为什么会发生拥塞？拥塞顾名思义就是像塞车那样发生了堵塞。通道的能力是一定的，当网球传输的压力逐渐增大的时候，那么就会发生了堵塞，甚至路由器的缓冲队列满了，直接把数据报丢掉。所以这里会有一个问题：数据传输慢了好多，甚至被丢包。然后会发生什么？超时重传。然后数据报一直发送不过去，这边一直重传，就形成了恶循环。导致整个网络瘫痪。所以一定要控制好流量。
这里的流量控制和上文讲滑动窗口的时候那个流量控制有什么区别？上文讲的流量控制是为了避免数据太快以致于接收端无法及时接受数据。这里是为了避免发生拥塞而导致网络瘫痪。但是都是同样的手段：流量控制。
导致拥塞的原因有什么？可以直接提高带宽解决吗？
拥塞控制不只是用到流量控制，导致拥塞的原因有：带宽，路由缓存，处理机处理速度等等非常多的因素。提高某个因素的能力会把瓶颈转移到其他的地方，所以能做的最重要一个就是控制流量。
拥塞的指标是什么？怎么判断发生了拥塞？
由于缺少缓存空间而被丢弃的分组的百分数；
平均队列长度；
超时重传的分组数；
平均分组时延；
分组时延的标准差，等等
- 开环控制：在网络执行前进行预估尽量避免
- 闭环控制：实时监控控制
减少拥塞有两种方案：一种是硬件的能力，这个只能尽量，但是提升空间小，瓶颈大，第二种就是通过算法来减少，也就是tcp要做的。
tcp的拥塞控制方法
首先来看一张图，这张图就讲了整个tcp控制拥塞的算法：
一共有4个点：慢开始，拥塞避免，快重传，快恢复。
概述
tcp控制拥塞的算法核心就是动态窗口。上面我们讲到，发送端可以发送的最多数据报是根据接收端的缓冲区以及自身的缓冲区大小决定，但是我们不能任他无限大发送。如果每个链接都发送50g的数据岂不是得炸掉。所以这里增加了一个拥塞窗口，控制可以发送的数据数量，控制流量。
因为动态窗口需要根据情况实时调整，所以，必须得到及时的反馈，所以接收端收到数据报的时候，需要迅速把确认发送给发送端。
快重传
这个算法要求当接收端发现缺少包的时候要及时反映给发送端。例如发送了1，2但是3丢了，此时继续发送4，5，6，那么接收端就要返回三个重复确认，3还没来就发4,5,6肯定是你的3丢了，赶紧重发。然后接受端收到三个重复的，就赶紧补发3过去。
慢开始
这里的慢开始就是一开始的窗口值要小，不能太大，然后去试探拥塞的底线。这里一般的起点是一般是发送端一个数据报可以发送的最大长度的1~2倍。然后每一个轮次，也就一个往返，就把窗口值加倍。这里的往返要注意一下，是要整个窗口中的数据全部往返一次，才算是一个轮次。例如窗口的大小是8，那么需要8的数据报都收到ack才算是一个轮次结束。
拥塞避免
这里有一个界限，如果一直增大下去那岂不是就指数爆炸了。所以到了一个界限：ssthresh，这个值是自己设定的。之后就是以线性慢慢增长。然后就会出现两种情况：
- 发生超时重传
- 得到三个重复的ack
首先看第一种情况，如果发生了超时重传，则说明很可能是发生了拥塞，那么这个时候就要迅速慢开始，把ssthresh设置当前窗口大小的1/2，然后把窗口压缩到最初的状态。重头开始。第二种情况就是快恢复了。
快恢复
当收到三个重复的ack的时候，只是有可能但是可能性比较小出现了拥塞，所以就把ssthresh设置为当前窗口的1/2，同时把当前窗口值设置为何ssthresh一样大。不用慢开始直接拥塞避免阶段。
窗口值上限
这个上限就是前面讲到的根据两端缓存区的大小来确定了。
主动队列管理AQM
如果发生拥塞，那么会瞬间让整个网络的效率降低到很小的一个值，所以要尽量避免，多一点快恢复。
我们知道路由器的缓冲队列长度是有限的，当满了之后接下来的分组都会被丢弃那么，我们可以在快满的时候就通知慢点发送，快拥塞了。管理好这个队列，而不能等到发生事故了在进行处理。这就是主动队列管理。
TCP的运输连接管理
tcp是面向连接的，所以就涉及到连接的建立释放。那么连接就有状态，就涉及到有限状态机。也就是以下三个：
连接建立
这个有个很重要的概念：三次握手。
他们建立的过程类似这样：
- client：我要和你连接
- service：好的，你真的要连接吗
- client：对，我真的要
然后就连接了。这个过程需要发送三个报文，也称为三报文握手。然后互相交换各自的信息例如窗口值 RTT等。相亲的互问根底不过是为了婚姻更幸福的生活不是吗（此处手动滑稽）
连接释放
释放的话会比较麻烦一点，毕竟闪婚容易，离婚就可能和庆兄或者祥哥一样可爱了。（哦祥哥貌似当时还没结婚）释放连接要进行4次握手：
- client：我不要你了我要释放连接
- service：你真的不要我了吗，哼，不要就滚
- service：我决定了。释放连接
- client：好，拜拜。
- client：等待2msl时间后完全释放连接
最后一个是一个等待时间，避免受到无效的请求。因为进行了四次握手也成为四报文握手。（也有叫挥手的，挥手比较好点）这样就直接释放连接了。这里有几个点要注意：
- 客户端请求释放，受到服务端的确认后并没有完全释放连接，而是会等待服务端的下一个回复才真正断开。但是，还不是完全断开，要再等两个最大报文生存时间，网络中完全不存在无效报文了再彻底断开。
- 另外等待时间也是为了最后一个报文能到达服务端，万一服务端反悔了就可以收到对吧，如果没有等待2msl，就可能下一个tcp连接收到了无效的请求。
有限状态机
通过上面的讲述可以发现tcp连接存在很多的状态。所以也就有了这个状态机。给个图你们感受一下：
总结
这篇文章从什么是运输层，运输层的协议，到重点介绍tcp的工作原理，如何可靠传输，tcp报的格式，到更加深入的拥塞原理，流量控制提高传输效率，最后讲了tcp的连接管理。
tcp是运输层一个非常重要的协议，除了少部分使用udp，其他基本都是使用tcp，所以要对tcp的原理模清楚。另外要懂得tcp的效率问题以及出错的拥塞问题连接问题。
运输层是直接和我们应用层打交道的，所以了解清楚运输层是有必要的。当我们需要建立一些socket连接的时候，就必须对运输层有一定的了解。
好了关于运输层就大概讲这么多，希望可以给你们有一些帮助。
