C++服务端面试准备（5）网络协议相关

声明：本文内容纯属博主自己查找和归纳的个人所需的知识点，仅作参考，如有错误，博主强烈希望您指出。如果您是某个知识点的原创博主，如有需要，可联系本人加上链接。本文内容会根据博主所需进行更新，希望大家多多关照。

由于博主不是计算机专业出身，个人能力有限，本文内容涉及到博主的知识盲区，在这领域不知道需要掌握多少，只是把自己看到的大概归纳一下，请见谅。也希望网友们可以指点指点，谢谢！

网络层次划分

TCP/IP 4层模型：应用层、传输层、网络层、网络接口层
TCP/IP 5层模型：应用层、传输层、网络层、数据链路层、物理层
OSI 7层模型：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层

• 物理层：发送高低电压即电信号
• 数据链路层：电信号分组，以太网协议，单位为帧
• 网络层：对子网间的数据包进行路由选择，IP协议，单位为IP数据报
• 传输层：负责端到端的可靠数据传输，网关，TCP协议和UDP协议
• 会话层：进程间的会话
• 表示层：数据的加密、压缩、格式转换等
• 应用层：应用程序

以太网数据包

       以太网数据包的头为14字节，包括源地址、目标地址、数据类型，尾4字节。

       数据部分最短46字节，最长1500字节，这个大小称为MTU（最长传输单元），内容为IP数据报，报头占20字节。因此以太网包最短64字节，最长1518字节

       数据部分超过MTU就分片发送，分片需包含IP头和TCP/UDP头

       以TCP为例，以太网数据包数据部分有2000字节，包含IP头20字节，TCP头20字节（UDP8字节），以及应用数据1960字节，需要做分片操作，第一部分1500字节，包含IP头20字节，TCP头20字节，应用数据1460字节（这个值称为最大报文段长度MSS），第二部分540字节，包含IP头20字节，TCP头20字节，应用数据500字节

       另外，1492的MTU值的来源，是因为PPPoE协议。PPP协议是宽带运营商用于对用户认证计费的（TCP/IP以太网无此功能）。PPPoE头尾一共8字节，所以有效载荷MTU变小了，原来有1500字节，现在只剩1492

TCP协议和UDP协议

       TCP传输控制协议协议是是一种面向连接的、可靠的、基于字节流的传输层通信协议。

       TCP/IP协议是Internet最基本的协议、Internet国际互联网络的基础，由网络层的IP协议和传输层的TCP协议组成。通俗而言：TCP负责发现传输的问题，一有问题就发出信号，要求重新传输，直到所有数据安全正确地传输到目的地。而IP是给因特网的每一台联网设备规定一个地址。

       UDP用户数据报协议，是面向无连接的通讯协议，由于通讯不需要连接，所以可以实现广播发送。UDP通讯时不需要接收方确认，属于不可靠的传输，可能会出现丢包现象，实际应用中要求程序员编程验证（例如模拟TCP的连接和断开，要保证数据的有效性、有序性）。

       TCP 与 UDP 的区别：TCP是面向连接的，可靠的字节流服务；UDP是面向无连接的，不可靠的数据报服务。

三次握手和四次挥手

三次握手：

• 客户端发送SYN报文给服务端，进入SYN-SEND状态；
• 服务端收到SYN报文后发送SYN+ACK报文给客户端，进入SYN-RCVD状态；
• 客户端收到SYN+ACK报文后发送ACK报文给服务端，双方进入ESTABLISED状态

四次挥手：

• 客户端发送FIN报文给服务端，进入FIN_WAIT-1状态；
• 服务端收到FIN报文，发送ACK报文，继续回复完客户端前面的事务，进入CLOSE-WAIT，客户端收到ACK报文后进入FIN-WAIT-2状态，接收服务端剩下的回复；
• 服务端也发送FIN报文给客户端，进入LAST-ACK状态；
• 客户端收到FIN报文后发送ACK报文给服务端，进入TIME-WAIT状态，如果服务端没有收到ACK报文则可以重传FIN报文，服务端收到ACK报文后关闭服务

为什么3次握手

       假设改为两次握手，client端发送的一个连接请求在服务器滞留了，由于连接超时client端会放弃，这个连接请求是无效的，但等到服务器收到这个无效的请求，服务器还是会继续认为client想要建立一个新的连接，于是就建立连接了，服务器此时会一直等client端发数据，这样就浪费掉很多server端的资源

为什么4次挥手

       如果客户端在收到服务器给它的断开连接的请求之后，回应完服务器就直接断开连接的话，如果因为一些原因，服务器没有收到回应，会以为客户端还没关闭，这样服务器就会一直开着。所以客户端要等待两个最长报文段寿命的时间，以便于服务器没有收到请求之后重新发送请求。
       在释放连接的过程中会有一些无效的滞留报文，这些报文在经过2MSL的时间内就可以发送到目的地，不会滞留在网络中。这样就可以避免在下一个连接中出现上一个连接的滞留报文了

Socket通信流程

• 服务端这边首先创建一个Socket（Socket()），然后绑定IP地址和端口号（Bind()），之后注册监听（Listen()），这样服务端就可以监听指定的Socket地址了；
• 客户端这边也创建一个Socket（Socket()）并打开，然后根据服务器IP地址和端口号向服务器Socket发送连接请求（Connect()）；
• 服务器Socket监听到客户端Socket发来的连接请求之后，被动打开，并调用Accept()函数接收请求，这样客户端和服务器之间的连接就建立好了；
• 成功建立连接之后客户端和服务器就可以进行数据交互（Receive()、Send()）；
• 交互完之后，各自关闭连接（Close()），交互结束。

拥塞控制

       参考：TCP慢启动、拥塞避免、快速重传、快速恢复

       背景：为了防止网络的拥塞现象，TCP提出了一系列的拥塞控制机制。最初由V. Jacobson在1988年的论文中提出的TCP的拥塞控制由“慢启动(Slow start)”和“拥塞避免(Congestion avoidance)”组成，后来TCP Reno版本中又针对性的加入了“快速重传(Fast retransmit)”、“快速恢复(Fast Recovery)”算法，再后来在TCP NewReno中又对“快速恢复”算法进行了改进，近些年又出现了选择性应答( selective acknowledgement,SACK)算法，还有其他方面的大大小小的改进，成为网络研究的一个热点

       TCP的拥塞控制主要原理依赖于一个拥塞窗口(cwnd)来控制，还有一个对端的接收窗口(rwnd)用于流量控制。因此TCP的真正的发送窗口=min(rwnd, cwnd)。但是rwnd是由对端确定的，网络环境对其没有影响，所以在考虑拥塞的时候我们一般不考虑rwnd的值，我们暂时只讨论如何确定cwnd值的大小。

       关于cwnd的单位，在TCP中是以字节来做单位的，假设TCP每次传输都按照MSS大小来发送数据，则可以认为cwnd按照数据包个数来做单位，所以有时我们说cwnd增加1也就是相当于字节数增加1个MSS大小。

慢启动
       当新建连接时，cwnd初始化为1个最大报文段(MSS)大小，发送端开始按照拥塞窗口大小发送数据，每当有一个报文段被确认，cwnd就增加1个MSS大小。这样cwnd的值就随着网络往返时间(RTT)呈指数级增长，事实上，慢启动的速度一点也不慢，只是它的起点比较低一点而已。我们可以简单计算下：

       开始 ---> cwnd = 1
       经过1个RTT后 ---> cwnd = 2 * 1 = 2
       经过2个RTT后 ---> cwnd = 2 * 2 = 4
       经过3个RTT后 ---> cwnd = 4 * 2 = 8

       如果带宽为W，那么经过RTT*log2W时间就可以占满带宽

拥塞避免
       从慢启动可以看到，cwnd可以很快的增长上来，从而最大程度利用网络带宽资源，但是cwnd不能一直这样无限增长下去，一定需要某个限制。TCP使用了一个叫慢启动门限(ssthresh)的变量，当cwnd超过该值后，慢启动过程结束，进入拥塞避免阶段。对于大多数TCP实现来说，ssthresh的值是65536(同样以字节计算)。拥塞避免的主要思想是加法增大，也就是cwnd的值不再指数级往上升，开始加法增加。此时当窗口中所有的报文段都被确认时，cwnd的大小加1，cwnd的值就随着RTT开始线性增加，这样就可以避免增长过快导致网络拥塞，慢慢的增加调整到网络的最佳值。

       拥塞现象的判定：TCP对每一个报文段都有一个定时器，称为重传定时器(RTO)，当RTO超时且还没有得到数据确认，那么TCP就会对该报文段进行重传。当发生超时时，出现拥塞的可能性就很大，某个报文段可能在网络中某处丢失，并且后续的报文段也没有了消息，在这种情况下，TCP反应比较“强烈”：

       1.把ssthresh降低为cwnd值的一半
       2.把cwnd重新设置为1
       3.重新进入慢启动过程

       从整体上来讲，TCP拥塞控制窗口变化的原则是AIMD原则，即加法增大、乘法减小

快速重传
       其实TCP还有一种情况会进行重传：那就是收到3个相同的ACK。TCP在收到乱序到达包时就会立即发送ACK，TCP利用3个相同的ACK来判定数据包的丢失，此时进行快速重传，快速重传做的事情有：

       1.把ssthresh设置为cwnd的一半
       2.把cwnd再设置为ssthresh的值(具体实现有些为ssthresh+3)
       3.重新进入拥塞避免阶段

快速恢复
       后来的“快速恢复”算法是在上述的“快速重传”算法后添加的，当收到3个重复ACK时，TCP最后进入的不是拥塞避免阶段，而是快速恢复阶段。快速重传和快速恢复算法一般同时使用。

       快速恢复的思想是“数据包守恒”原则，即同一个时刻在网络中的数据包数量是恒定的，只有当“老”数据包离开了网络后，才能向网络中发送一个“新”的数据包，如果发送方收到一个重复的ACK，那么根据TCP的ACK机制就表明有一个数据包离开了网络，于是cwnd加1。如果能够严格按照该原则那么网络中很少会发生拥塞，事实上拥塞控制的目的也就在修正违反该原则的地方。

       具体来说快速恢复的主要步骤是：

       1.当收到3个重复ACK时，把ssthresh设置为cwnd的一半，把cwnd设置为ssthresh的值加3，然后重传丢失的报文段。（加3的原因是因为收到3个重复的ACK，表明有3个“老”的数据包离开了网络）
       2.如果再收到同样的重复的ACK，拥塞窗口就再增加1，但ssthresh的值不变，如果是新的重复的ACK，则到达3个又重复第一步的动作。
       3.当收到新的数据包的ACK时，把cwnd设置为第一步中的ssthresh的值。（原因是因为该ACK确认了新的数据，说明从重复ACK时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态）

       然而在实际中，一个重传超时可能导致许多的数据包的重传，当多个数据包从一个数据窗口中丢失时并且触发快速重传和快速恢复算法时，问题就产生了。

       因此NewReno出现了，它在Reno快速恢复的基础上稍加了修改，可以恢复一个窗口内多个包丢失的情况。具体来讲就是：Reno在收到一个新的数据的ACK时就退出了快速恢复状态了，而NewReno需要收到该窗口内所有数据包的确认后才会退出快速恢复状态，从而更一步提高吞吐量

选择性应答(SACK)算法
       SACK就是改变TCP的确认机制，最初的TCP只确认当前已连续收到的数据，SACK则把乱序等信息会全部告诉对方，从而减少数据发送方重传的盲目性。

       例如，序号1，2，3，5，7的数据收到了，普通的ACK只会确认序列号4，而SACK会把当前的5，7已经收到的信息在SACK选项里面告知对端，对端就能直接重发序号4和6的数据，不用再在序号6的数据上花时间，从而提高性能。

       当使用SACK的时候，NewReno算法可以不使用，因为SACK本身携带的信息就可以使得发送方有足够的信息来知道需要重传哪些包，而不需要重传哪些包。

HTTP(可选)

       超文本传输协议HTTP是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。

请求包
       当浏览器向Web服务器发出请求时，它向服务器传递了一个数据块，也就是请求信息，HTTP请求信息由3部分组成：

l 请求方法URI协议/版本
l 请求头(Request Header)

l 请求正文

       下面是一个HTTP请求的例子：

GET/sample.jspHTTP/1.1
Accept:image/gif.image/jpeg,/
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate

username=jinqiao&password=1234

HTTP 协议包括的请求：

• GET：请求读取由URL所标志的信息。
• POST：给服务器添加信息（如注释）。

（Get是从服务器上获取数据，Post是向服务器传送数据）

• PUT：在给定的URL下存储一个文档。
• DELETE：删除给定的URL所标志的资源。
• HEAD：类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头
• CONNECT：HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器
• OPTIONS：允许客户端查看服务器的性能。
• TRACE：回显服务器收到的请求，主要用于测试或诊断。
• PATCH：是对 PUT 方法的补充，用来对已知资源进行局部更新 。

       请求头和响应头的信息参考：HTTP 请求包和响应包 （网络篇）

响应包
       HTTP响应也由3个部分构成，分别是：

l　协议状态版本代码描述
l　响应头(Response Header)

l　响应正文

       下面是一个HTTP响应的例子：

HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112