Let's study some things about the Http protocol together today. Through this article, you will learn the following:
Comparison and advantages and disadvantages of various versions of Http protocol
Http2.0 protocol-related SPDY protocol, binary framing protocol, multiplexing, header compression, service push and other basic principles
HTTP3.0 and QUIC protocols
Ride the wind and waves to the ocean of knowledge, it's time to sail!
1. Comparison of various versions of the Http protocol
The Http hypertext transfer protocol is like air, its existence is not felt but it is ubiquitous . The author has extracted some simple information about the development process of the Http protocol from Wikipedia. Let’s take a look:
Hypertext Transfer Protocol is an application protocol for distributed collaborative hypermedia information systems . The Hypertext Transfer Protocol is the basis for data communication on the World Wide Web, where hypertext documents include hyperlinks to other resources that users can easily access.
Tim Berners-Lee initiated the development of Hypertext Transfer Protocol at CERN in 1989. The development of early HTTP Requests for Comments (RFCs) was a joint effort between the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C), whose work was later transferred to the IETF.
About Tim Berners-Lee, Father of the World Wide Web
Tim Berners-Lee is a British engineer and computer scientist, best known as the inventor of the World Wide Web. He is Professor of Computer Science at Oxford University and a professor at MIT .
He proposed an information management system on March 12, 1989, and then realized the first .
He is director of the World Wide Web Consortium (W3C), which oversees the continued development of the Web, founder of the World Wide Web Foundation , and 3Com Founder-Chair and Senior Fellow at CSAIL, MIT's computer science and artificial intelligence laboratory. Also director of the Network Science Research Initiative WSRI and a member of the advisory board of the MIT Center for Collective Intelligence, he is also the founder and is currently an advisor to the social network MeWe.
In 2004, Berners-Lee was knighted by Queen Elizabeth II for . In April 2009, he was elected as a foreign researcher of the National Academy of Sciences of the United States, and was listed in Time Magazine's list of the 100 most important people of the 20th century . He was hailed as the "Inventor of the World Wide Web" and won the 2016 Turing Award .
Basic situation of each version of http
After more than 20 years of evolution of the http protocol, there have been five major versions of 0.9 , 1.0, 1.1, 2.0, and 3.0. The author drew a picture to see:
A.Http0.9 version
0.9 is the original version, its main features include:
Request method support is limited.
Only GET request method is supported, and other request methods are not supported. Therefore, the amount of information transmitted from the client to the server is very limited, that is, the commonly used Post request cannot be used now.
The request header does not support
the version number specified in the request, and the server only has the ability to return HTML strings
The response is
to close the TCP connection immediately after the server responds.
B.Http1.0 version
Version 1.0 is mainly an enhancement of version 0.9, and the effect is more obvious. The main features and shortcomings include:
Rich request method
The request method adds POST, DELETE, PUT, HEADER and other methods, which improves the magnitude of the information sent by the client to the server
Add request header and response header
Add the concept of request header and response header, you can specify the HTTP protocol version number and other header information in the communication, making C/S interaction more flexible and convenient
Rich data transmission content
expands the transmission content format, including: pictures, audio and video resources, binary , etc. can be transmitted. Compared with 0.9, which can only transmit html content, http has more application scenarios
Poor link reusability
In version 1.0, each TCP connection can only send one request, and the connection will be closed after the data is sent. If other resources are requested, the connection must be re-established. In order to ensure correctness and reliability, TCP requires three handshakes and four handshakes between the client and server, so the cost of establishing a connection is very high, and the sending rate is slow at the beginning based on congestion control, so the performance of version 1.0 is not ideal .
Disadvantages
of stateless and connectionless version 1.0 is stateless and connectionless . In other words, the server does not track or record the requested state. The client needs to establish a tcp connection for each request and cannot be reused, and 1.0 stipulates that the previous The next request can only be sent after the request response arrives. If the previous one is blocked, the subsequent request will be blocked. Packet loss and out-of-sequence problems and high-cost connection processes cause many problems in multiplexing and head-of-line blocking , so connectionless and stateless is a weakness of version 1.0 .
C.Http1.1 version
Version 1.1 was launched about one year after the release of version 1.0. It is an optimization and improvement of version 1.0. The main features of version 1.1 include:
Add a new Connection field for long connections
, you can set the keep-alive value to keep the connection from disconnecting, that is, the TCP connection is not closed by default, and can be reused by multiple requests. This is also a very important optimization of version 1.1, but the S-side server only handles After one response is completed, the next response will be performed. If the front response is particularly slow, there will be many requests waiting in line later, and there will still be head-of-line blocking problems.
On the basis of long connection, pipelining
can continue to send subsequent requests without waiting for the first request response, but the order of responses is still returned in the order of requests, that is, in the same TCP connection, the client can send multiple requests at the same time. requests, further improving the transmission efficiency of the HTTP protocol.
More request methods
Add PUT, PATCH, OPTIONS, DELETE and other request methods.
host field
The Host field is used to specify the domain name of the server, so that multiple requests can be sent to different websites on the same server, which improves the reuse of the machine. This is also an important optimization
D.Http2.0 version
Version 2.0 is a milestone version. Compared with version 1.x, it has a lot of optimizations to adapt to the current network scenario. Several important features include:
Binary format
1.x is a text protocol, but 2.0 uses binary frames as the basic unit. It can be said that it is a binary protocol that divides all transmitted information into messages and frames, and uses binary format encoding. One frame contains data and Identifiers make network transmission efficient and flexible.
Multiplexing
is a very important improvement. In 1.x, there are problems with the consumption and efficiency of establishing multiple connections. In version 2.0, multiple requests share one connection, and multiple requests can be processed simultaneously in one TCP The concurrency of the connection is mainly distinguished by the identification in the binary frame to realize the multiplexing of the link.
Header compression
version 2.0 uses the HPACK algorithm to compress the header data, thereby reducing the size of the request and improving efficiency. This is very easy to understand. Previously, the same header was sent every time, which seemed very redundant. Version 2.0 is correct Incremental update of internal information effectively reduces the transmission of header data.
The server-side push
function is a bit interesting. Before the 1.x version, the server was executed passively after receiving the request. In the 2.0 version, the server is allowed to actively send resources to the client, which can accelerate the client.
2. Http2.0 detailed explanation
The evolution and optimization process of several versions were compared before, and then some features and basic implementation principles of the next version 2.0 will be studied in depth.
From a comparison point of view, version 2.0 is not an optimization of version 1.1 but an innovation , because version 2.0 is burdened with more performance target tasks . Although 1.1 adds long connections and pipelines, it fundamentally does not achieve real high performance. performance.
The design goal of 2.0 is to bring users a faster, simpler, and safer experience on the basis of compatibility with 1.x semantics and operations . Efficiently utilize the current network bandwidth. For this reason, 2.0 has made many adjustments, mainly including: Binary Framing, multiplexing, header compression , etc.
Akamai made a comparison between http2.0 and http1.1 in the loading process (in the experiment, the loading time of loading 379 small fragments on the author's computer is 0.99s VS 5.80s):
https://http2.akamai.com/demo
2.1 SPDY protocol
To talk about version 2.0 standards and new features, you must mention Google's SPDY protocol . Take a look at Baidu Encyclopedia:
SPDY是Google开发的基于TCP的会话层协议，用以最小化网络延迟，提升网络速度，优化用户的网络使用体验。SPDY并不是一种用于替代HTTP的协议，而是对HTTP协议的增强。
新协议的功能包括 数据流的多路复用、请求优先级以及HTTP报头压缩。谷歌表示引入SPDY协议后，在实验室测试中页面加载速度比原先快64%。
随后SPDY协议得到Chrome、Firefox等大型浏览器的支持，在一些大型网站和小型网站种部署，这个高效的协议引起了HTTP工作组的注意，在此基础上制定了官方Http2.0标准。
之后几年SPDY和Http2.0继续演进相互促进，Http2.0让服务器、浏览器和网站开发者在新协议中获得更好的体验，很快被大众所认可。
2.2 二进制分帧层
二进制分帧层binary framing layer在不修改请求方法和语义的基础上，重新设计了编码机制，如图为http2.0分层结构(图片来自参考4)：
二进制编码机制使得通信可以在单个TCP连接上进行，该连接在整个对话期间一直处于活跃状态。
二进制协议将通信数据分解为更小的帧，数据帧充斥在C/S之间的双向数据流中，就像双向多车道的高速路，来往如织川流不息：
要理解二进制分帧层需要知道四个概念：
链接Link
就是指一条C/S之间的TCP链接，这是个基础的链路数据的高速公路
数据流Stream
已建立的TCP连接内的双向字节流，TCP链接中可以承载一条或多条消息
消息Message
消息属于一个数据流，消息就是逻辑请求或响应消息对应的完整的一系列帧，也就是帧组成了消息
帧Frame
帧是通信的最小单位，每个帧都包含帧头和消息体，标识出当前帧所属的数据流
四者是一对多的包含关系，笔者画了一张图：
再来看一下HeadersFrame头部帧的结构：
再来看一下HeadersFrame头部帧的结构：从各个域可以看到长度、类型、标志位、流标识符、数据净荷等，感兴趣可以阅读rfc7540相关文档。
https://httpwg.org/specs/rfc7540.html
总之2.0版本将通信数据分解为二进制编码帧进行交换，每个帧对应着特定数据流中的特定消息，所有帧和流都在一个TCP连接内复用，二进制分帧协议是2.0其他功能和性能优化的重要基础。
2.3 多路复用
1.1版本中存在队首阻塞问题，因此如果客户端要发起多个并行请求来提升性能，必须使用多个TCP连接，这样就要承受更大延时和建链拆链成本，不能有效利用TCP链接。
由于2.0版本中使用新的二进制分帧协议突破了1.0的诸多限制，从根本上实现了真正的请求和响应多路复用。
客户端和服务器将交互数据分解为相互独立的帧，互不影响地交错传输，最后再在对端根据帧头中的流标识符把它们重新组装起来，从而实现了TCP链接的多路复用。
如图展示了2.0版本的基于帧的消息通信过程(图片来自参考4)：
2.4 首部压缩
A.Header冗余传输
我们都知道http请求都有header部分，每个包都有并且相对于一条链接而言大部分的包的header部分都是相同的，这样的话每次传输相同的部分确实非常浪费。
现代网络中每个网页平均包含100多个http请求，每个请求头平均有300-500字节，总数据量达到几十KB以上，这样可能造成数据延时，尤其复杂 的WiFi环境或者蜂窝网络，这样只能看到手机在转圈，但是这些请求头之间通常几乎没有变化，在本已经拥挤的链路中多次传输相同的数据部分确实不是高效做法。
基于TCP设计的 拥塞控制具有 线增积减AIMD特性，如果发生丢包那么传输速率将大幅度下降，这样在拥挤的网络环境中大的包头意味着只能 加剧拥塞控制造成的低速率传输。
B.Http压缩和犯罪攻击
在2.0版本的HPACK算法之前，http压缩使用gzip去压缩，后来提出的SPDY算法对Headers进行特殊设计，但是它依旧使用的是DEFLATE算法。
在后面的一些实际应用中发现DEFLATE和SPDY都有被攻击的危险，因为DEFLATE算法使用后向字符串匹配和动态Huffman编码，攻击者可以控制部分请求头部通过修改请求部分然后看压缩之后大小改变多少，如果变小了攻击者就知道注入的文本和请求中的某些内容有重复。
这个过程有点像俄罗斯方块的消除过程，这样经过一段时间的尝试数据内容就可能被全部搞清楚，由于这种风险的存在才研发出更安全的压缩算法。
C.HPACK算法
2.0版本中HPACK算法在C/S中使用首部表来存储之前发送的键值对，对于相同的数据通信期间几乎不会改变的通用键值对只需发送一次即可。
极端情况如果请求头每次没有变化，那么传输中则不包含首部，也就是首部开销就是零字节。如果首部键值对发生变化了，也只需要发送变化的数据，并且将新增或修改的首部帧会被追加到首部表，首部表在链接存活期始终存在, 并且由客户端和服务器共同更新和维护。
简单说就是客户端和服务端共同维护了一个key-value的结构，发生变化时则更新传输，否则就不传输，这样相当于首次全量传输之后增量更新传输即可，这个思想在日常开发中也非常普遍，不用想的太复杂。
如图展示了首部表的更新过程(图片来自参考4)：
hpack算法的相关文档：
https://tools.ietf.org/html/draft-ietf-httpbis-header-compression-12
2.5 服务端推送
服务端推送是2.0版本新增的一个强大功能，和一般的一问一答式的C/S交互不同，推送式交互中服务器可以对客户端的一个请求发送多个响应，除了对最初请求的响应外还向客户端推送额外资源，无需客户端明确地请求也可以推送。
举个栗子：
想象一下你去餐厅吃饭，服务好的快餐厅在你点好一份牛肉面之后，还会给你送上餐巾纸、筷子、勺子甚至调料等，这样主动式的服务，节约了客人的时间并且提高了用餐体验。
在实际的C/S交互中这种主动推送额外资源的方法很有效，因为几乎每个网络应用都会包含多种资源，客户端需要全部逐个获取它们，此时如果让服务器提前推送这些资源，从而可以有效减少额外的延迟时间，因为服务器可以知道客户端下一步要请求什么资源。
如图为服务端推送的简单过程(图片来自参考4)：
3.HTTP2.0和HTTP3.0
科技永不止步。
我们都知道互联网中业务是不断迭代前进的，像HTTP这种重要的网络协议也是如此，新版本是对旧版本的扬弃。
3.1 HTTP2.0和TCP的爱恨纠葛
HTTP2.0是2015年推出的，还是比较年轻的，其重要的二进制分帧协议、多路复用、头部压缩、服务端推送等重要优化使HTTP协议真正上了一个新台阶。
像谷歌这种重要的公司并没有满足于此，而且想继续提升HTTP的性能，花最少的时间和资源获取极致体验。
那么肯定要问HTTP2.0虽然性能已经不错了，还有什么不足吗？
建立连接时间长(本质上是TCP的问题)
队头阻塞问题
移动互联网领域表现不佳(弱网环境)
......
熟悉HTTP2.0协议的同学应该知道，这些缺点基本都是由于TCP协议引起的，水能载舟亦能覆舟，其实TCP也很无辜呀！
在我们眼里，TCP是面向连接、可靠的传输层协议，当前几乎所有重要的协议和应用都是基于TCP来实现的。
网络环境的改变速度很快，但是TCP协议相对缓慢，正是这种矛盾促使谷歌做出了一个看似出乎意料的决定-基于UDP来开发新一代HTTP协议。
3.2 谷歌为什么选择UDP
上文提到，谷歌选择UDP是看似出乎意料的，仔细想一想其实很有道理。
我们单纯地看看TCP协议的不足和UDP的一些优点：
基于TCP开发的设备和协议非常多，兼容困难
TCP协议栈是Linux内部的重要部分，修改和升级成本很大
UDP本身是无连接的、没有建链和拆链成本
UDP的数据包无队头阻塞问题
UDP改造成本小
从上面的对比可以知道，谷歌要想从TCP上进行改造升级绝非易事，但是UDP虽然没有TCP为了保证可靠连接而引发的问题，但是UDP本身不可靠，又不能直接用。
综合而知，谷歌决定在UDP基础上改造一个具备TCP协议优点的新协议也就顺理成章了，这个新协议就是QUIC协议。
3.3 QUIC协议和HTTP3.0
QUIC其实是Quick UDP Internet Connections的缩写，直译为快速UDP互联网连接。
我们来看看维基百科对于QUIC协议的一些介绍：
QUIC协议最初由Google的Jim Roskind设计，实施并于2012年部署，在2013年随着实验的扩大而公开宣布，并向IETF进行了描述。
QUIC提高了当前正在使用TCP的面向连接的Web应用程序的性能。它在两个端点之间使用用户数据报协议（UDP）建立多个复用连接来实现此目的。
QUIC的次要目标包括减少连接和传输延迟，在每个方向进行带宽估计以避免拥塞。它还将拥塞控制算法移动到用户空间，而不是内核空间，此外使用前向纠错（FEC）进行扩展，以在出现错误时进一步提高性能。
HTTP3.0又称为HTTP Over QUIC，其弃用TCP协议，改为使用基于UDP协议的QUIC协议来实现。
4. QUIC协议详解
择其善者而从之，其不善者而改之。
HTTP3.0既然选择了QUIC协议，也就意味着HTTP3.0基本继承了HTTP2.0的强大功能，并且进一步解决了HTTP2.0存在的一些问题，同时必然引入了新的问题。
QUIC协议必须要实现HTTP2.0在TCP协议上的重要功能，同时解决遗留问题，我们来看看QUIC是如何实现的。
4.1 队头阻塞问题
队头阻塞 Head-of-line blocking（缩写为HOL blocking）是计算机网络中是一种性能受限的现象，通俗来说就是：一个数据包影响了一堆数据包，它不来大家都走不了。
队头阻塞问题可能存在于HTTP层和TCP层，在HTTP1.x时两个层次都存在该问题。
HTTP2.0协议的多路复用机制解决了HTTP层的队头阻塞问题，但是在TCP层仍然存在队头阻塞问题。
TCP协议在收到数据包之后，这部分数据可能是乱序到达的，但是TCP必须将所有数据收集排序整合后给上层使用，如果其中某个包丢失了，就必须等待重传，从而出现某个丢包数据阻塞整个连接的数据使用。
QUIC协议是基于UDP协议实现的，在一条链接上可以有多个流，流与流之间是互不影响的，当一个流出现丢包影响范围非常小，从而解决队头阻塞问题。
4.2 0RTT 建链
衡量网络建链的常用指标是RTT Round-Trip Time，也就是数据包一来一回的时间消耗。
RTT包括三部分：往返传播时延、网络设备内排队时延、应用程序数据处理时延。
一般来说HTTPS协议要建立完整链接包括:TCP握手和TLS握手，总计需要至少2-3个RTT，普通的HTTP协议也需要至少1个RTT才可以完成握手。
然而，QUIC协议可以实现在第一个包就可以包含有效的应用数据，从而实现0RTT，但这也是有条件的。
简单来说，基于TCP协议和TLS协议的HTTP2.0在真正发送数据包之前需要花费一些时间来完成握手和加密协商，完成之后才可以真正传输业务数据。
但是QUIC则第一个数据包就可以发业务数据，从而在连接延时有很大优势，可以节约数百毫秒的时间。
QUIC的0RTT也是需要条件的，对于第一次交互的客户端和服务端0RTT也是做不到的，毕竟双方完全陌生。
因此，QUIC协议可以分为首次连接和非首次连接，两种情况进行讨论。
4.3 首次连接和非首次连接
使用QUIC协议的客户端和服务端要使用1RTT进行密钥交换，使用的交换算法是DH(Diffie-Hellman)迪菲-赫尔曼算法。
DH算法开辟了密钥交换的新思路，在之前的文章中提到的RSA算法也是基于这种思想实现的，但是DH算法和RSA的密钥交换不完全一样，感兴趣的读者可以看看DH算法的数学原理。
DH算法开辟了密钥交换的新思路，在之前的文章中提到的RSA算法也是基于这种思想实现的，但是DH算法和RSA的密钥交换不完全一样，感兴趣的读者可以看看DH算法的数学原理。
4.3.1 首次连接
简单来说一下，首次连接时客户端和服务端的密钥协商和数据传输过程，其中涉及了DH算法的基本过程：
客户端对于首次连接的服务端先发送client hello请求。
服务端生成一个素数p和一个整数g，同时生成一个随机数 (笔误-此处应该是Ks_pri)为私钥，然后计算出公钥 = mod p，服务端将，p，g三个元素打包称为config，后续发送给客户端。
客户端随机生成一个自己的私钥，再从config中读取g和p，计算客户端公钥 = mod p。
客户端使用自己的私钥和服务端发来的config中读取的服务端公钥，生成后续数据加密用的密钥K = mod p。
客户端使用密钥K加密业务数据，并追加自己的公钥，都传递给服务端。
服务端根据自己的私钥和客户端公钥生成客户端加密用的密钥K = mod p。
为了保证数据安全，上述生成的密钥K只会生成使用1次，后续服务端会按照相同的规则生成一套全新的公钥和私钥，并使用这组公私钥生成新的密钥M。
服务端将新公钥和新密钥M加密的数据发给客户端，客户端根据新的服务端公钥和自己原来的私钥计算出本次的密钥M，进行解密。
之后的客户端和服务端数据交互都使用密钥M来完成，密钥K只使用1次。
4.3.2 非首次连接
前面提到客户端和服务端首次连接时服务端传递了config包，里面包含了服务端公钥和两个随机数，客户端会将config存储下来，后续再连接时可以直接使用，从而跳过这个1RTT，实现0RTT的业务数据交互。
客户端保存config是有时间期限的，在config失效之后仍然需要进行首次连接时的密钥交换。
4.4 前向安全问题
前向安全是密码学领域的专业术语，看下百度上的解释：
前向安全或前向保密Forward Secrecy是密码学中通讯协议的安全属性，指的是长期使用的主密钥泄漏不会导致过去的会话密钥泄漏。
前向安全能够保护过去进行的通讯不受密码或密钥在未来暴露的威胁，如果系统具有前向安全性，就可以保证在主密钥泄露时历史通讯的安全，即使系统遭到主动攻击也是如此。
通俗来说，前向安全指的是密钥泄漏也不会让之前加密的数据被泄漏，影响的只有当前，对之前的数据无影响。
前面提到QUIC协议首次连接时先后生成了两个加密密钥，由于config被客户端存储了，如果期间服务端私钥泄漏，那么可以根据K = mod p计算出密钥K。
如果一直使用这个密钥进行加解密，那么就可以用K解密所有历史消息，因此后续又生成了新密钥，使用其进行加解密，当时完成交互时则销毁，从而实现了前向安全。
4.5 前向纠错
前向纠错是通信领域的术语，看下百科的解释：
前向纠错也叫前向纠错码Forward Error Correction 简称FEC 是增加数据通讯可信度的方法，在单向通讯信道中，一旦错误被发现，其接收器将无权再请求传输。
FEC 是利用数据进行传输冗余信息的方法，当传输中出现错误，将允许接收器再建数据。
听这段描述就是做校验的，看看QUIC协议是如何实现的：
QUIC每发送一组数据就对这组数据进行异或运算，并将结果作为一个FEC包发送出去，接收方收到这一组数据后根据数据包和FEC包即可进行校验和纠错。
4.6 连接迁移
网络切换几乎无时无刻不在发生。
TCP协议使用五元组来表示一条唯一的连接，当我们从4G环境切换到wifi环境时，手机的IP地址就会发生变化，这时必须创建新的TCP连接才能继续传输数据。
QUIC协议基于UDP实现摒弃了五元组的概念，使用64位的随机数作为连接的ID，并使用该ID表示连接。
基于QUIC协议之下，我们在日常wifi和4G切换时，或者不同基站之间切换都不会重连，从而提高业务层的体验。
5. QUIC的应用和前景
通过前面的一些介绍我们看出来QUIC协议虽然是基于UDP来实现的，但是它将TCP的重要功能都进行了实现和优化，否则使用者是不会买账的。
QUIC协议的核心思想是将TCP协议在内核实现的诸如可靠传输、流量控制、拥塞控制等功能转移到用户态来实现，同时在加密传输方向的尝试也推动了TLS1.3的发展。
但是TCP协议的势力过于强大，很多网络设备甚至对于UDP数据包做了很多不友好的策略，进行拦截从而导致成功连接率下降。
主导者谷歌在自家产品做了很多尝试，国内腾讯公司也做了很多关于QUIC协议的尝试。
其中腾讯云对QUIC协议表现了很大的兴趣，并做了一些优化然后在一些重点产品中对连接迁移、QUIC成功率、弱网环境耗时等进行了实验，给出了来自生产环境的诸多宝贵数据。
简单看一组腾讯云在移动互联网场景下的不同丢包率下的请求耗时分布：
任何新生事物的推动都是需要时间的，出现多年的HTTP2.0和HTTPS协议的普及度都没有预想高，IPv6也是如此，不过QUIC已经展现了强大的生命力，让我们拭目以待吧！
6.本文小结
本文通过介绍Http协议的历史演进、各个版本的主要特征和优缺点、重点介绍了Http2.0协议的一些特性，包括：SPDY协议、二进制分帧协议、多路复用、首部压缩、服务端推送等重要功能，篇幅有限不能展开太多。
虽然http2.0版本协议有很多非常优秀的功能并且在2015年正式发布，现在国内外一些大厂基本都有使用http2.0承担部分请求，但是目前仍然未广泛普及。
目前http3.0版本在2018年也推出来了，至于http2.0和http3.0的推广和普及是需要时间的，但是坚信我们的网络可以更安全、更快捷、更节约。
不过现在看看QUIC协议：基于UDP主体将TCP的重要功能转移到用户空间来实现，从而绕开内核实现用户态的TCP协议，但是真正实现起来还是非常复杂的。
网络协议本身就很复杂，本文只能从整体出发对重要的部分做粗浅的阐述，如果对某个点很感兴趣，可以查阅相关代码和RFC文档。