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

<html>
<head>
<title>HTTP响应示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>

HTTP答应码：

• 1XX－信息类(Information),表示收到Web浏览器请求，正在进一步的处理中
• 2XX－成功类（Successful）,表示用户请求被正确接收，理解和处理例如：200 OK
• 3XX-重定向类(Redirection),表示请求没有成功，客户必须采起进一步的动做。
• 4XX-客户端错误(Client Error)，表示客户端提交的请求有错误 例如：404 NOT Found，意味着请求中所引用的文档不存在。
• 5XX-服务器错误(Server Error)表示服务器不能完成对请求的处理：如 500

其余

       想实现网络通讯，每台主机需具有四要素：本机的IP地址、子网掩码、网关的IP地址、DNS的IP地址

获取这四要素分两种方式：
       1.静态获取 即手动配置
       2.动态获取 经过dhcp获取

       DHCP（动态主机配置协议）是一个局域网的网络协议。指的是由服务器控制一段lP地址范围，客户机登陆服务器时就能够自动得到服务器分配的lP地址和子网掩码。