From TCP/IP To MEC
Last updated
Was this helpful?
Last updated
Was this helpful?
最初国际标准化组织ISO定义了网络七层参考模型OSI，随着互联网技术的大规模发展实际形成了以TCP/IP网络为代表的五层结构：硬件层、网络接口层、互联网层、传输层和应用层。
简单来说，硬件/物理层定义了物理信号，例如有线通信的电信号、光信号，无线通信里的电磁波信号；网络接口层完成信号的数字化，将物理信号变成数字化逻辑信道；IP层定义了路由，完成数据包的分组交换，包括了封装/解封装、转发等；传输层建立起了连接（Connection），在点对点通信中双方以某个端口对建立起连接；应用层建立起了会话（Session），实际的数据载荷开始传输了。
无状态
无状态是指IP通信双方不同步传输数据的状态信息，所有IP数据报的发送、传输、接受都是相互独立、没有上下文关系的。这种服务优点在于简单、高效。最大的缺点是无法处理乱序和重复的IP数据报，确保IP数据报完整的工作只能交给上层协议来完成。
无连接
无连接是指IP通信双方都不长久地维持对方的任何信息。上层协议每次发送数据的时候，都需要明确指出对方的IP地址。
不可靠
不可靠是指IP协议不能保证IP数据报准确到达接收端，它指承诺尽最大努力交付。IP模块一旦检测到数据报发送失败，就通知上层协议，而不会试图重传。
在TCP/IP网络体系结构中，TCP（传输控制协议，Transport Control Protocol）、UDP（用户数据报协议，User Data Protocol）是传输层最重要的两种协议，为上层用户提供级别的通信可靠性。
传输控制协议（TCP）：TCP（传输控制协议）定义了两台计算机之间进行可靠的传输而交换的数据和确认信息的格式，以及计算机为了确保数据的正确到达而采取的措施。协议规定了TCP软件怎样识别给定计算机上的多个目的进程如何对分组重复这类差错进行恢复。协议还规定了两台计算机如何初始化一个TCP数据流传输以及如何结束这一传输。TCP最大的特点就是提供的是面向连接、可靠的字节流服务。
用户数据报协议（UDP）：UDP（用户数据报协议）是一个简单的面向数据报的传输层协议。提供的是非面向连接的、不可靠的数据流传输。UDP不提供可靠性，也不提供报文到达确认、排序以及流量控制等功能。它只是把应用程序传给IP层的数据报发送出去，但是并不能保证它们能到达目的地。因此报文可能会丢失、重复以及乱序等。但由于UDP在传输数据报前不用在客户和服务器之间建立一个连接，且没有超时重发等机制，故而传输速度很快。
“面向连接”就是在正式通信前必须要与对方建立起连接，是按照电话系统建模的。比如你给别人打电话，必须等线路接通了、对方拿起话筒才能相互通话。
TCP协议是一种可靠的、一对一的、面向有连接的通信协议，TCP主要通过下列几种方式保证数据传输的可靠性：
（1）在使用TCP协议进行数据传输时，往往需要客户端和服务端先建立一个“通道“、且这个通道只能够被客户端和服务端使用，所以TCP传输协议只能面向一对一的连接。
（2）为了保证数据传输的准确无误，TCP传输协议将用于传输的数据包分为若干个部分（每个部分的大小根据当时的网络情况而定），然后在它们的首部添加一个检验字节。当数据的一个部分被接收完毕之后，服务端会对这一部分的完整性和准确性进行校验，校验之后如果数据的完整度和准确度都为100%，在服务端会要求客户端开始数据下一个部分的传输，如果数据的完整性和准确性与原来不相符，那么服务端会要求客户端再次传输这个部分。
客户端与服务端在使用TCP传输协议时要先建立一个“通道”，在传输完毕之后又要关闭这“通道”，前者可以被形象地成为“三次握手”，而后者则可以被称为“四次挥手”。
通道的建立——三次握手：
（1）在建立通道时，客户端首先要向服务端发送一个SYN同步信号。
（2）服务端在接收到这个信号之后会向客户端发出SYN同步信号和ACK确认信号。
（3）当服务端的ACK和SYN到达客户端后，客户端与服务端之间的这个“通道”就会被建立起来。
通道的关闭——四次挥手：
（1）在数据传输完毕之后，客户端会向服务端发出一个FIN终止信号。
（2）服务端在收到这个信号之后会向客户端发出一个ACK确认信号。
（3）如果服务端此后也没有数据发给客户端时服务端会向客户端发送一个FIN终止信号。
（4）客户端在收到这个信号之后会回复一个确认信号，在服务端接收到这个信号之后，服务端与客户端的通道也就关闭了。
TCP协议能为应用程序提供可靠的通信连接，使一台计算机发出的字节流无差错地发往网络上的其他计算机，对可靠性要求高的数据通信系统往往使用TCP协议传输数据。
TCP 通过维护一个拥塞窗口来进行拥塞控制，拥塞控制的原则是，只要网络中没有出现拥塞，拥塞窗口的值就可以再增大一些，以便把更多的数据包发送出去，但只要网络出现拥塞，拥塞窗口的值就应该减小一些，以减少注入到网络中的数据包数。
TCP 拥塞控制算法发展的过程中出现了如下几种不同的思路：
基于丢包的拥塞控制：将丢包视为出现拥塞，采取缓慢探测的方式，逐渐增大拥塞窗口，当出现丢包时，将拥塞窗口减小，如 Reno、Cubic 等。
基于时延的拥塞控制：将时延增加视为出现拥塞，延时增加时增大拥塞窗口，延时减小时减小拥塞窗口，如 Vegas、FastTCP 等。
基于链路容量的拥塞控制：实时测量网络带宽和时延，认为网络上报文总量大于带宽时延乘积时出现了拥塞，如 BBR。
基于学习的拥塞控制：没有特定的拥塞信号，而是借助评价函数，基于训练数据，使用机器学习的方法形成一个控制策略，如 Remy。
Vegas
Vegas将时延 RTT 的增加作为网络出现拥塞的信号，RTT 增加，拥塞窗口减小，RTT 减小，拥塞窗口增加。具体来说，Vegas 通过比较实际吞吐量和期望吞吐量来调节拥塞窗口的大小，
期望吞吐量：Expected = cwnd / BaseRTT，
实际吞吐量：Actual = cwnd / RTT，
diff = (Expected-Actual) * BaseRTT，
BaseRTT 是所有观测来回响应时间的最小值，一般是建立连接后所发的第一个数据包的 RTT，cwnd 是目前的拥塞窗口的大小。Vegas 定义了两个阈值 a，b，当 diff > b 时，拥塞窗口减小，当 a <= diff <=b 时，拥塞窗口不变，当 diff < a 时，拥塞窗口增加。
Vegas 算法采用 RTT 的改变来判断网络的可用带宽，能精确地测量网络的可用带宽，效率比较好。但是，网络中 Vegas 与其它算法共存的情况下，基于丢包的拥塞控制算法会尝试填满网络中的缓冲区，导致 Vegas 计算的 RTT 增大，进而降低拥塞窗口，使得传输速度越来越慢，因此 Vegas 未能在 Internet 上普遍采用。
适用场景：适用于网络中只存在 Vegas 一种拥塞控制算法，竞争公平的情况。
Reno
Reno将拥塞控制的过程分为四个阶段：慢启动、拥塞避免、快重传和快恢复，是现有的众多拥塞控制算法的基础，下面详细说明这几个阶段。
慢启动阶段，在没有出现丢包时每收到一个 ACK 就将拥塞窗口大小加一（单位是 MSS，最大单个报文段长度），每轮次发送窗口增加一倍，呈指数增长，若出现丢包，则将拥塞窗口减半，进入拥塞避免阶段；当窗口达到慢启动阈值或出现丢包时，进入拥塞避免阶段，窗口每轮次加一，呈线性增长；当收到对一个报文的三个重复的 ACK 时，认为这个报文的下一个报文丢失了，进入快重传阶段，立即重传丢失的报文，而不是等待超时重传；快重传完成后进入快恢复阶段，将慢启动阈值修改为当前拥塞窗口值的一半，同时拥塞窗口值等于慢启动阈值，然后进入拥塞避免阶段，重复上诉过程。
Reno 算法将收到 ACK 这一信号作为拥塞窗口增长的依据，在早期低带宽、低时延的网络中能够很好的发挥作用，但是随着网络带宽和延时的增加，Reno 的缺点就渐渐体现出来了，发送端从发送报文到收到 ACK 经历一个 RTT，在高带宽延时（High Bandwidth-Delay Product，BDP）网络中，RTT 很大，导致拥塞窗口增长很慢，传输速度需要经过很长时间才能达到最大带宽，导致带宽利用率将低。
适用场景：适用于低延时、低带宽的网络。
Cubic
Cubic是 Linux 内核 2.6 之后的默认 TCP 拥塞控制算法， 使用一个立方函数（cubic function）作为拥塞窗口的增长函数。
Cubic 拥塞窗口增长曲线如下，凸曲线部分为稳定增长阶段，凹曲线部分为最大带宽探测阶段。如图 2 所示，在刚开始时，拥塞窗口增长很快，在接近 Wmax 口时，增长速度变的平缓，避免流量突增而导致丢包；在 Wmax 附近，拥塞窗口不再增加；之后开始缓慢地探测网络最大吞吐量，保证稳定性（在 Wmax 附近容易出现拥塞），在远离 W max 后，增大窗口增长的速度，保证了带宽的利用率。
当出现丢包时，将拥塞窗口进行乘法减小，再继续开始上述增长过程。此方式可以使得拥塞窗口一直维持在 Wmax 附近，从而保证了带宽的利用率。Cubic 的拥塞控制过程如图所示：
Cubic 算法的优点在于只要没有出现丢包，就不会主动降低自己的发送速度，可以最大程度的利用网络剩余带宽，提高吞吐量，在高带宽、低丢包率的网络中可以发挥较好的性能。
但是，Cubic 同之前的拥塞控制算法一样，无法区分拥塞丢包和传输错误丢包，只要发现丢包，就会减小拥塞窗口，降低发送速率，而事实上传输错误丢包时网络不一定发生了拥塞，但是传输错误丢包的概率很低，所以对 Cubic 算法的性能影响不是很大。
Cubic 算法的另一个不足之处是过于激进，在没有出现丢包时会不停地增加拥塞窗口的大小，向网络注入流量，将网络设备的缓冲区填满，出现 Bufferbloat（缓冲区膨胀）。由于缓冲区长期趋于饱和状态，新进入网络的的数据包会在缓冲区里排队，增加无谓的排队时延，缓冲区越大，时延就越高。另外 Cubic 算法在高带宽利用率的同时依然在增加拥塞窗口，间接增加了丢包率，造成网络抖动加剧。
适用场景：适用于高带宽、低丢包率网络，能够有效利用带宽。
BBR
BBR是谷歌在 2016 年提出的一种新的拥塞控制算法，已经在 Youtube 服务器和谷歌跨数据中心广域网上部署，据 Youtube 官方数据称，部署 BBR 后，在全球范围内访问 Youtube 的延迟降低了 53%，在时延较高的发展中国家，延迟降低了 80%。目前 BBR 已经集成到 Linux 4.9 以上版本的内核中。
BBR 算法不将出现丢包或时延增加作为拥塞的信号，而是认为当网络上的数据包总量大于瓶颈链路带宽和时延的乘积时才出现了拥塞，所以 BBR 也称为基于拥塞的拥塞控制算法（Congestion-Based Congestion Control）。BBR 算法周期性地探测网络的容量，交替测量一段时间内的带宽极大值和时延极小值，将其乘积作为作为拥塞窗口大小（交替测量的原因是极大带宽和极小时延不可能同时得到，带宽极大时网络被填满造成排队，时延必然极大，时延极小时需要数据包不被排队直接转发，带宽必然极小），使得拥塞窗口始的值始终与网络的容量保持一致。
由于 BBR 的拥塞窗口是精确测量出来的，不会无限的增加拥塞窗口，也就不会将网络设备的缓冲区填满，避免了出现 Bufferbloat 问题，使得时延大大降低。如图所示，网络缓冲区被填满时时延为 250ms，Cubic 算法会继续增加拥塞窗口，使得时延持续增加到 500ms 并出现丢包，整个过程 Cubic 一直处于高时延状态，而 BBR 由于不会填满网络缓冲区，时延一直处于较低状态。
由于 BBR 算法不将丢包作为拥塞信号，所以在丢包率较高的网络中，BBR 依然有极高的吞吐量，如图 5 所示，在 1% 丢包率的网络环境下，Cubic 的吞吐量已经降低 90% 以上，而 BBR 的吞吐量几乎没有受到影响，当丢包率大于 15% 时，BBR 的吞吐量才大幅下降。
BBR 算法是反馈驱动的，有自主调节机制，不受 TCP 拥塞控制状态机的控制，通过测量网络容量来调整拥塞窗口，发送速率由自己掌控，而传统的拥塞控制算法只负责计算拥塞窗口，而不管发送速率（pacing rate），怎么发由 TCP 自己决定，这样会在瓶颈带宽附近因发送速率的激增导致数据包排队或出现丢包。
BBR 算法的不足之处在于设备队列缓存较大时，BBR 可能会竞争不过 Cubic 等比较激进算法，原因是 BBR 不主动去占据队列缓存，如果 Cubic 的流量长期占据队列缓存，会使得 BBR 在多个周期内测量的极小 RTT 增大，进而使 BBR 的带宽减小。
适用场景：适用于高带宽、高时延、有一定丢包率的长肥网络，可以有效降低传输时延，并保证较高的吞吐量。
Remy
Remy也称为计算机生成的拥塞控制算法（computer-generated congestion-control algorithm），采用机器学习的方式生成拥塞控制算法模型。通过输入各种参数模型（如瓶颈链路速率、时延、瓶颈链路上的发送者数量等），使用一个目标函数定量判断算法的优劣程度，在生成算法的过程中，针对不同的网络状态采用不同的方式调整拥塞窗口，反复修改调节方式，直到目标函数最优，最终会生成一个网络状态到调节方式的映射表，在真实的网络中，根据特定的网络环境从映射表直接选取拥塞窗口的调节方式。
Remy 试图屏蔽底层网络环境的差异，采用一个通用的拥塞控制算法模型来处理不同的网络环境。这种方式比较依赖输入的训练集（历史网络模型），如果训练集能够全面覆盖所有可能出现的网络环境及拥塞调节算法，Remy 算法在应用到真实的网络环境中时能够表现的很好，但是如果真实网络与训练网络差异较大，Remy 算法的性能会比较差。
适用场景：网络环境为复杂的异构网络，希望计算机能够针对不同网络场景自动选择合适的拥塞控制方式，要求现有的网络模型能够覆盖所有可能出现情况。
高延迟 – 带来页面加载速度的降低
无状态特性 – 带来巨大的 HTTP 头部
明文传输 – 带来不安全性
由于 HTTP/1.x 的缺陷，我们会引入雪碧图、将小图内联、使用多个域名等方式来提高性能，不过这些优化都绕开了协议。直到 2009 年，谷歌公开了自行研发的 SPDY 协议，主要解决 HTTP/1.1 效率不高的问题。谷歌推出 SPDY，才算是正式改造 HTTP 协议本身。降低延迟，压缩 header 等等，SPDY 的实践证明了这些优化的效果，也最终带来 HTTP/2 的诞生。
二进制传输
Header 压缩
多路复用
服务器推送
Google 在推 SPDY 的时候就已经意识到了这些问题，于是就另起炉灶搞了一个基于 UDP 协议的“QUIC”协议，让 HTTP 跑在 QUIC 上而不是 TCP 上。而这个“HTTP over QUIC”就是 HTTP 协议的下一个大版本，HTTP/3。它在 HTTP/2 的基础上又实现了质的飞跃，真正“完美”地解决了“队头阻塞”问题。
实现了类似 TCP 的流量控制、传输可靠性的功能
虽然 UDP 不提供可靠性的传输，但 QUIC 在 UDP 的基础之上增加了一层来保证数据可靠性传输。它提供了数据包重传、拥塞控制以及其他一些 TCP 中存在的特性。
实现了快速握手功能
由于 QUIC 是基于 UDP 的，所以 QUIC 可以实现使用 0-RTT 或者 1-RTT 来建立连接，这意味着 QUIC 可以用最快的速度来发送和接收数据，这样可以大大提升首次打开页面的速度。0RTT 建连可以说是 QUIC 相比 HTTP2 最大的性能优势。
集成了 TLS 加密功能
目前 QUIC 使用的是 TLS1.3，相较于早期版本 TLS1.3 有更多的优点，其中最重要的一点是减少了握手所花费的 RTT 个数。
多路复用，彻底解决 TCP 中队头阻塞的问题
和 TCP 不同，QUIC 实现了在同一物理连接上可以有多个独立的逻辑数据流（如下图）。实现了数据流的单独传输，就解决了 TCP 中队头阻塞的问题。
DNS（DNS、DNS over TLS，DNS over HTTPS）
SSL/TLS
QUIC
NDN与NEW IP
研究目的
原有的IP协议栈在不同类型的网络中（WLAN、LTE/NR、BLE、IoT等）缺乏良好的互通性能
原有的IP协议具有固定的格式的地址长度（IPv4为32bit，IPv6为128bit），这使得在密集的小数据包场景下的开销过大，不具备良好的“伸缩性”
原有的优先级/流级别的调度方式不能适应更细粒度的网络流量管理的需要
原有的IP地址是面向物理主机的映射，随着如今越来越多的虚拟化对象和服务，这样的模式不再合理
NEW IP的关键特性
长度可变的IP地址，以无缝支持跨网络通信
IP地址的语义定义，以标识物理和虚拟对象
用户定义的IP标头，允许最终用户指定对数据包执行的自定义功能
优点
快速交付：无需DNS查询
服务中心化：面向服务而不是地址
业务优化：服务类型可以用来提升QoE
