计算机网络(学习过程中--持续更新)

一、OSI七层协议、TCP/IP四层协议、五层协议都讲一讲

OSI七层协议

1. 应用层：为特定的应用程序提供服务，例如SMTP(电子邮件)、HTTP、DNS等等进行数据传输
2. 表示层：将应用处理的信息转换为适合网络传输的格式
3. 会话层：负责建立和断开通信连接
4. 传输层：这一层的协议主要有TCP、UDP，用于主机与主机之间进行数据传输的
5. 网络层：这一层的协议是IP协议，地址管理和路由选择
6. 数据链路层：负责物理层面上互联的、节点之间的通信传输
7. 物理层：负责0、1比特流与电压的高低、光的闪灭之间的互换

TCP/IP四层协议

1. 应用层：将OSI参考模型中的会话分层、表示层和应用层的功能都集中到了应用程序中实现
2. 传输层：TCP、UDP协议，提供数据的可靠传输
3. 网络层：IP协议，负责地址管理和路由选择
4. 网络接口层：利用以太网的数据链路层进行通信和比特流进行物理传输

五层协议

1. 应用层
2. 传输层
3. 网络层
4. 数据链路层
5. 物理层

图表总结

二、TCP、UDP

TCP协议

TCP协议，也就是传输控制协议。
它是：

• 面向连接、可靠、基于字节流的传输层通信协议
• 将应用层的数据流分割成报文段传输到目标节点的TCP层
• 数据包都有序号，对方收到则发送ACK确认，否则会重传
• 使用校验和来校验数据在传输过程中是否有误

UDP协议

它是：

• 面向无连接、不可靠、基于报文的传输层通信协议
• 不维护连接状态，支持同时向多个客户端传输相同的消息
• 数据包报头只有8个字节，额外开销较少
• 吞吐量不受拥塞拥挤算法的调节，只受限于数据生成速率、传输速率以及机器性能
• 尽最大努力交付，不保证可靠交付，不需要维持复杂的链接状态表
• UDP协议比TCP协议传输速度要快，因为它直接将应用层传输下来的报文添加首部然后传至下方IP层，既不拆分也不合并

TCP和UDP的区别

• 面向连接 vs 面 向无连接：TCP信息传输是要建立连接的，而UDP不需要，它适合一个点到多个点的传输
• 可靠性：TCP是通过握手和重传机制提供可靠性保证，而UDP可能会丢失
• 有序性：TCP利用序列号保证数据的顺序交付，到达可能无序，但TCP会最终排序，而UDP不具备有序性的
• 速度：TCP速度比较慢，因为要创建连接，保证数据的可靠性和有序性，所以就需要做更多的额外操作，而UDP适合对速度比较敏感的应用，比如在线视频媒体、电视广播、多人在线游戏等
• 量级：TCP属于重量级的，UDP属于轻量级的，体现在源数据的头大小，TCP是20个字节，而UDP是8个字节

TCP三次握手

握手流程

• 第一次握手：客户端发送一个SYN(seq=x)的报文段给服务端
• 第二次握手：服务端发送一个SYN(seq=y)+ACK(ack=x+1)的报文段给客户端
• 第三次握手：客户端发送一个ACK(seq=y+1)的报文段给服务端

为什么要进行三次握手？两次、四次不行吗？

第一次握手是请求建立客户端到服务端的传输通道，第二次握手是确认客户端到服务端的传输通道正常并且请求建立服务端到客户端的传输通道，第三次握手是确认服务端到客户端传输通道正常。三次握手刚好保证这两个通道都能正常传输，两次少了，四次又多了。

TCP首次握手的隐患–SYN超时

问题起因
由于Server端收到Client端的SYN，回复SYN-ACK的时候未收到ACK确认，Server会不断重试发送SYN-ACK的包，直至超时。
对于SYN Flood的防护措施
SYN队列满后，通过tcp_syncookies参数回发SYN Cookie
若正常连接则Client会回发SYN Cookie，直接建立连接
建立连接后，Client出故障怎么办
会有一个保活机制，就是会向对方发送保活探测报文，如果为收到响应就继续发送，会有一个提前设置好的保活时间间隔，如果在规定时间内没有得到回复，就会中断连接

TCP四次挥手

挥手流程

• 第一次挥手：客户端传输完数据后，会向服务端发送一个FIN的报文，用于关闭客户端到服务端的传输通道，客户端进入到FIN-WAIT-1状态
• 第二次挥手：服务端接收到客户端发送的FIN报文，它会立即回复一个ACK的报文，用于确认关闭客户端到服务端的传输通道，服务端进入到CLOSE-WAIT状态
• 第三次挥手：服务端传输完数据，会向客户端发送一个FIN的报文，服务端进入LAST-ACK状态
• 第四次挥手：客户端接收到服务端发来的FIN报文，回复一个ACK的报文，用于确认关闭服务端到客户端的传输通道，客户端进入到TIME-WAIT(2MSL)状态,然后服务端进入到CLOSED状态，客户端等过完2MSL(MaximumSegmentLifetime)时间后也进入到CLOSED状态

挥手时为什么会有TIME-WAIT状态

确保有足够的时间让对方收到ACK包，一来一去正好2MSL的时间

为什么是四次挥手？

因为TCP连接是全双工服务，发送方和接收方都需要FIN报文和ACK报文来关闭通道和确认关闭通道

TCP的特点及其目的

TCP的特点就是传输可靠的，如果达到传输可靠，必须要解决数据的破坏、丢包、重复以及分片顺序混乱等问题
TCP通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输

TCP是如何确保可靠性传输的

通过序列号与确认应答提高可靠性

在TCP中，当发送端的数据到达接受主机时，接收端主机会返回一个消息，这个消息叫做确认应答(ACK)
TCP通过肯定的确认应答(ACK)来保证数据的可靠传输，当发送端发送出去数据后，发送端就会等待接收端发回的确认应答，如果接收到了确认应答， 那就说明发送的这批数据已经成功发送到对端了，如果一段时间后没有收到这个确认应答，那么就会考虑在数据传输中是否发生丢包，这个时候发送端就会进行重发。由此，即使产生丢包，也能够保证数据能够到达对端，实现可靠传输。
这个时候丢包有两种可能：

• 数据包丢失的情况： 在发送的过程中由于网络拥堵，导致丢包。这种情况下会进行重新发送，保证数据能够正确到达接收端
• 确认应答丢失的情况 接收端接收到这批数据，然后接收端给发送端回发消息后，在这个过程中，导致丢包。这种情况发送端也会进行重新发送，但是接收端接收到这个数据之后会把它丢弃，然后接收端再回发一个ACK。

上面这些涉及到的确认应答处理、重发控制以及重复控制等功能都可以通过序列号实现。发送端发送一个数据包(1~100)，当接收端接收到之后，将自己下一步应该接受的序号作为确认应答返送回去。就这样，通过序列号和确认应答号，TCP可以实现可靠传输。

重发超时如何确定

重发超时是指在重发数据之前，等待确认应答到来的那个特定的时间间隔。如果超过了这个时间还没有收到确认应答，那么发送端将进行数据重发。那么这个重发超时的具体时间长度又是如何确定的呢？

TCP要求不论在任何网络环境下都要提供高性能，并且无论网络堵塞发生何种变化，都必须保持这一特性。它会计算每次发包的往返时间(RTT)及其偏差，重发超时就是比这个总和要稍大一点的值。

重发超时的计算既要考虑往返时间又要考虑偏差是有其原因的。根据网络环境的情况，数据包的往返时间可能会产生大幅度摇摆，之所以发生这种情况是因为数据包的分段是经过不同线路到达的，TCP/IP的目的是即使在这种环境下也要进行控制，尽量不要浪费网络流量

在BSD的Unix以及Windows系统中，超时都以0.5秒为单位的(最小偏差值为0.5，因此最小的重发时间至少是1秒)，在最初的数据包还不知道往返时间，所以其重发超时一般设置为6秒。

数据进行重发之后，如果收不到确认应答，则会再次进行重发。但是重发的次数也不能是无限的，等到一定的次数，会认为网络原因或者对端出问题了，而强制中断连接。

TCP以段为单位发送数据

在建立TCP连接的同时，也可以确定发送数据包的单位，我们也可以称其为“最大消息长度”(MSS)，TCP在传送大量数据的时候就是以MSS的大小将数据进行分割发送。进行重发时也是以MSS为单位的。

那么这个MSS是如何计算出来的呢？它是在TCP三次握手建立连接的时候确定的。第一次握手的时候，客户端建议MSS设置为某个长度size1，第二次握手的时候，服务端建议MSS设置为某个长度size2。最后第三次握手确定这两个size中较小的一个，发送数据。

利用窗口控制提高速度

TCP以1个段为单位，每发一个段都需要收到一个确认应答的处理。但是这样的传输方式有一个缺点。那就是，包的往返时间越长通信性能就会越差。

针对上面的问题，TCP引入了窗口的概念，即使在往返时间较长的情况下，它也能控制网络性能的下降。此时，确认应答不再是以一个段为单位了，而是以一个更大的单位进行确认。这样转发时间就会大幅度的缩短。

在收到确认应答的情况，将窗口滑动到确认应答中序列号的位置。这样可以顺序地将多个段同时发送提高通信性能。这种机制也被称为滑动窗口控制。

窗口控制与重发控制

提到这个窗口，那么窗口的大小就是大家关心的，窗口的大小是谁决定的呢？它是取决于接收端处理数据的能力大小确定的。这里涉及到一个缓冲区的概念，缓冲区表示临时保存收发数据的场所。发送端将数据发送给接收端，接收端回复确认应答的时候捎上剩余缓冲区的大小，这个大小就是下次传输的窗口大小。

在窗口里的数据，发送端将它们发送出去之后，发送端需要设置缓存来保存这些数据，直到收到对应的确认应答才会从缓存中清楚，如果没有收到确认应答，就会将这个数据重新发送，这里又会牵扯到一个概念高速重发，在我们之前提到的，如果发送端没有收到确认应答的话，经历重发超时的时间后会进行重发，但是在这里，会有所不同，TCP设定，窗口中数据发送出去后，如果收到3次由接收端发送的确认应答的话，才会触发重发。这种机制比之前提到的超时管理更加高效。

在当窗口发送数据的时候，有一个丢包了，后面的也会继续发送。但是这块丢了怎么办。其实接收端在没有收到自己所期望序号的数据时，会对之前收到的数据进行确认应答。发送端则一旦收到某个确认应答后，又连续3次收到同样的确认应答，则认为数据段已经丢失，需要进行重发。

流控制

发送端根据自己的实际情况发送数据。但是某种情况下可能收到一个毫无关系的数据包又可能处理其他问题上花费一些时间。在高负荷的情况下，导致接收端无法接收任何数据，如此以来，如果接受端将本应该接收的数据丢弃的话，又会触发发送端的重发机制，这会造成网络流量的无端浪费，这个时候，需要有种机制来避免这种情况的发生。

TCP通过流量控制解决了这个问题。我们前面提到的缓冲区，就是跟这个机制有关。接收端会有一个缓冲区，用于存放待处理的数据，接收端每次接收到的数据就会将这个数据放入到这个缓冲区中，然后回复确认应答的时候，捎带上这个缓冲区剩余的大小。下次发送端会将这个大小设置为窗口的大小来进行发送数据。如果这个窗口大小是0的话，发送端将不会发送数据。

过了一个重发超时的时间以后，如果还没有收到窗口更新的通知的，发送端将会发送一个窗口探测的包，此数据只包含一个字节以获取最新的窗口大小信息。

拥塞控制

TCP采用窗口控制，在收发主机之间即使不再以一个数据段为单位发送确认应答，也能够连续发送大量数据包。然而，如果在通信刚开始的时候就发送大量数据也可能会引发其他问题。因为计算机网络是一个共享的环境，因此也有可能会因为其他主机之间的通信使得网络拥堵，当网络出现拥堵的时候，这时候突然发送一个较大量的数据，极有可能会导致整个网络的瘫痪。

TCP为了防止这种问题的发生，在通信一开始的时候会通过一个叫做慢启动的算法得出的数值，对发送的数据量进行控制。

为了在发送端调节所要发送数据的量，定义了一个叫做“拥塞窗口”的概念。在慢启动的时候，将这个窗口大小设为1个数据段(1MSS)发送数据，之后每一次应答拥塞窗口的值就+1。在发送数据包的时候，会将这个窗口大小和滑动窗口大小做比较，选择一个较小的值，发送比其还要小的数据量。

如果重发采用超时机制，那么拥塞窗口的初始值设置为1以后再及逆行慢启动修正。有了以上的机制，就可以有效地减少通信开始时连续发送数据包导致的网络拥堵的情况，还可以避免网络拥塞情况的发生。

不过随着包的每次往返，拥塞窗口也会以1、2、4等指数函数的增长，拥塞状况的激增甚至导致网络拥塞的发生。为了防止这些，引入了慢启动阀值得概念。只要拥塞窗口的值超过这个阀值得时候，在每收到一次确认应答时，会降低增长的幅度。

TCP的通信开始时，并没有设置相应的慢启动阀值。而是在超时重发时，才会设置为当时拥塞窗口一半的大小，初始默认值为1。而由重复确认应答进行告诉重发控制时，慢启动阀值的大小被设置为当时窗口一半后，将该窗口初始默认大小设置为慢启动阀值+3个数据段的大小。

HTTP协议

简介

当用户在浏览器的地址栏里输入所要访问的Web页面的URI以后，HTTP的处理立即开始，HTTP默认使用的是80端口。它的工作机制，首先是客户端向服务器的80端口建立一个TCP连接，然后在这个TCP连接上进行请求和应答以及数据报文的发送。

HTTP常用的有两个版本，一个是HTTP1.0，一个是HTTP1.1，在1.0的时候，它每发一个命令和应答都会建立一次TCP连接，而1.1版本开始，允许在一个TCP连接上发送多个命令和应答(keep-alive)，由此，减少了TCP连接的建立和断开操作，从而提高了效率

HTTP的主要命令以及响应码

HTTP的主要命令

HTTP主要命令
OPTIONS	设置选项
GET	获取指定URL的数据
HEAD	仅获取文档的首部
POST	请求服务器接收URI指定文档作为可执行的信息
PUT	请求服务器保存客户端传送的数据到URI指定文档
DELETE	请求服务器删除URI指定页面
TRACE	请求消息返回客户端

HTTP主要的状态码

1xx：服务器正常，可以继续发送请求

2xx：处理成功

200 成功：表示从客户端发来的请求在服务器被正常处理了
204 No Content：请求处理成功，但没有数据返回
206 Partial Content：请求处理成功，客户端只要其中一部分的数据

3xx：重定向

3xx响应结果表明浏览器需要执行某些特殊的处理以正确处理

301：永久性重定向，该状态码表示请求的资源已被分配了新的URI，以后使用资源现在所指的URI。也就是说，如果已经把资源对应的URI保存为书签了，下次就直接访问了
302：临时性重定向，该状态码表示请求的资源已被分配了新的URI，希望用户(本次)能使用新的URI访问

4xx：客户端错误

4xx的响应结果表明客户端是发生错误的原因所在

401 Unauthorized：该状态码表示发送的请求需要有通过HTTP认证(BASIC认证、DIGEST认证)的认证信息。
403 Forbidden：该状态码表明对请求资源的访问被服务器拒绝了。
404 Not Found：该状态码表明服务器上无法找到请求的资源。

5xx：服务端错误

5xx的响应结果表明服务器本身发生错误

500 Internal Server Error：该状态码表明服务器端在执行请求的时候发生了错误。
503 Service Unavailable：该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

确保Web安全的HTTPS

HTTP的缺点都有哪些

通信使用明文(不加密)，内容可能会被窃听

HTTP在进行TCP连接之后，相互进行数据传输，但是在传输过程中，这些内容是明文的，这样的数据包存在于互联网中很容易遭到窃听。

不验证通信方的身份，因此有可能遭遇伪装

HTTP在进行连接的时候，收到的请求它不会判断是谁发给自己的，它只需要自己收到请求然后处理，然后返回响应。这样的情况就可能遭遇伪装，任何人都可以发起请求。以上这些就有可能会出现以下各种隐患

• 无法确定请求发送至目标的web服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的web服务器。
• 无法确定响应返回到客户端是否是按照真实意图接受响应的那个客户端。有可能是已伪装的客户端
• 无法确定正在通信的对方是否具备访问权限。因为某些web服务器上保存着重要的信息，只想发给特定用户通信的权限
• 无法判定请求是来自何方、出自谁手。
• 即使是无意义的请求也会照单全收。无法阻止海量请求下的Dos攻击(Denial of Service，拒绝服务攻击)

无法证明报文的完整性，所以有可能以遭篡改

所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味着无法判断信息是否准确。也有可能接收到的内容可能有误。

由于上面HTTP的缺点，就出现了HTTPS

HTTPS=HTTP+加密+认证+完整性约束
我们之前是HTTP+TCP，而HTTPS是HTTP+SSL和TSL+TCP，说白了HTTPS是身披SSL外壳的HTTP。

相互交换秘钥的公开秘钥加密技术

HTTPS采用的是混合加密机制，也就是将共享秘钥加密和公开密钥加密两者混合的加密机制。HTTPS在客户端与服务器之间交换秘钥的步骤分为两步：

• 使用公开秘钥加密方式安全地交换在稍后的共享秘钥加密中使用的秘钥
• 确保交换的秘钥是安全的前提下，使用共享秘钥加密方式进行通信
  

证明公开秘钥正确性的证书

其实，上面说的公开密钥加密方式也是有漏洞的，就是说这个公开密钥本身就无法证明本身就是货真价实的公开秘钥。比如，正准备和某台服务器建立公开秘钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发型的公开秘钥。或许在公开秘钥传输途中，真正的公开密钥已经被攻击者替换掉了。

为了解决这个问题，可以使用由数字证书认证机构和其相关机关办法的公开秘钥证书。数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。

验证的流程：服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开秘钥加密方式通信。接到证书的客户端会通过SSL进行验证，验证通过，可以认定对端真实可靠、服务器的公开秘钥值得信赖。

HTTPS建立SSL连接的过程

三、DNS

DNS是如何寻址的

1、客户机发出查询请求，在本地计算机缓存查找，若没有找到，就会将请求发送给dns服务器
2、先发送给本地dns服务器，本地的就会在自己的区域里面查找，若找到，根据此记录进行解析，若没有找到，就会在本地的缓存里面查找
3、本地服务器没有找到客户机查询的信息，就会将此请求发送到根域名dns服务器
4、根域名服务器解析客户机请求的根域部分，它把包含的下一级的dns服务器的地址返回到客户机的dns服务器地址
5、客户机的dns服务器根据返回的信息接着访问下一级的dns服务器
6、这样递归的方法一级一级接近查询的目标，最后在有目标域名的服务器上面得到相应的IP信息
7、客户机的本地的dns服务器会将查询结果返回给我们的客户机
8、客户机根据得到的ip信息访问目标主机，完成解析过程