【面试】计网知识点复习与总结

短命女 2022-04-24 09:12 566阅读 0赞

# 【面试】计网知识点复习与总结 #

## 1. 计算机网络层次结构 ##

ISO/OSI七层网络模型与TCP/IP五层网络模型的比较如图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70]

*  **物理层**：它的主要作用是传输比特流，**进行模数转换与数模转换**，这一层的**数据叫做比特**。
 *  **数据链路层**：主要将从物理层接收的数据进行**MAC地址（网卡的地址）的封装与解封**。常把这一层的**数据叫做帧**。在这一层**工作的设备是交换机**。
 *  **网络层**：主要将从下层接收到的数据进行**IP地址的封装与解封**。在这一层**工作的设备是路由器**，常把这一层的**数据叫做数据包**。
 *  **传输层**：定义了一些传输数据的协议和端口号，主要是将从下层接收的**数据进行分段进行传输**，**到达目的地址后在进行重组**，常常把这一层**数据叫做段**。
 *  **会话层**：通过传输层（端口号：传输端口与接收端口）**建立数据传输的通路**。主要在你的系统之间发起会话或或者接受会话请求（设备之间需要互相认识可以是 IP 也可以是 MAC 或者是主机名）
 *  **表示层**：主要是进行对接收的数据**进行解释、加密与解密、压缩与解压缩**等（也就是把计算机能够识别的东西转换成人能够能识别的东西（如图片、声音等））
 *  **应用层**：终端的应用。

因为网络互相连接需要一些中间设备，而根据这些中间设备所在的不同层次，又分别被称为：

*  物理层：**转发器**
 *  数据链路层：**网桥**或者**桥接器**
 *  网络层：**路由器**
 *  网络层以上：**网关**

## 2. HTTP协议 ##

### 2.1 HTTP 请求过程 ###

1.  浏览器分析超链接指向页面的URL
2.  域名解析：
    
     *  浏览器搜索自身的DNS缓存
     *  浏览器搜索操作系统的DNS缓存
     *  浏览器尝试读取hosts文件
     *  浏览器向上一级DNS服务器请求
3.  DNS返回URL指向的IP地址
4.  发起TCP/IP的三次握手
5.  浏览器发送请求
6.  服务器响应请求，返回html页面
7.  TCP连接释放
8.  浏览器渲染页面

### 2.2 HTTP 报文格式 ###

**请求报文包含三部分：**

*  请求行：包含请求方法、URI、HTTP版本信息
 *  请求首部字段
 *  请求内容实体

**响应报文包含三部分：**

*  状态行：包含HTTP版本、状态码、状态码的原因短语
 *  响应首部字段
 *  响应内容实体

### 2.3 HTTP 首部 ###

通用首部字

*  Date：创建报文时间
 *  Connection：连接的管理
 *  Cache-Control：缓存的控制
 *  Transfer-Encoding：报文主体的传输编码方式

请求首部字段

*  Host：请求资源所在服务器
 *  Accept：可处理的媒体类型
 *  Accept-Charset：可接收的字符集
 *  Accept-Encoding：可接受的内容编码
 *  Accept-Language：可接受的自然语言

响应首部字段

*  Accept-Ranges：可接受的字节范围
 *  Location：令客户端重新定向到的
 *  URI Server：HTTP服务器的安装信息

实体首部字段（请求报文与响应报文的的实体部分使用的首部字段）

*  Allow：资源可支持的HTTP方法
 *  Content-Type：实体主类的类型
 *  Content-Encoding：实体主体适用的编码方式
 *  Content-Language：实体主体的自然语言
 *  Content-Length：实体主体的的字节数
 *  Content-Range：实体主体的位置范围，一般用于发出部分请求时使用

### 2.4 HTTP 请求方法 ###

*  GET：获取资源。
 *  POST：传输实体主体。
 *  PUT：上传文件（PS：由于自身不带验证机制，任何人都可以上传文件，因此存在安全性问题，一般不使用该方法）
 *  DELETE：删除文件。（PS：也不带验证机制）
 *  HEAD：获取报文首部（PS：请求不返回实体部分，主要用于确认 URL 的有效性以及资源更新的日期时间）
 *  PATCH：对资源进行部分修改（PS：PUT 也可以用于修改资源，但是只能完全替代原始资源，PATCH 允许部分修改）
 *  OPTION：查询指定的 URL 能够支持的方法。
 *  CONNECT：要求用隧道协议连接代理
 *  TRACE：追踪路径

**GET和POST方法的区别？**

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th align="center">GET</th> 
   <th align="center">POST</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>可缓存</td> 
   <td align="center">可以</td> 
   <td align="center">不可以</td> 
  </tr> 
  <tr> 
   <td>保留在浏览记录</td> 
   <td align="center">可以</td> 
   <td align="center">不可以</td> 
  </tr> 
  <tr> 
   <td>收藏为书签</td> 
   <td align="center">可以</td> 
   <td align="center">不可以</td> 
  </tr> 
  <tr> 
   <td>长度是否有限制</td> 
   <td align="center">有</td> 
   <td align="center">无</td> 
  </tr> 
  <tr> 
   <td>敏感数据传输</td> 
   <td align="center">不可以</td> 
   <td align="center">可以</td> 
  </tr> 
 </tbody> 
</table>

### 2.5 HTTP 状态码 ###

**1xx信息（信息性状态码）：接收的请求正在处理**

*  100 Continue：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。

**2xx信息（成功状态码）：请求已正常处理完毕**

*  200 OK：表示请求被服务器正常处理

*  204 No Content：表示请求已成功处理，但是没有内容返回，当浏览器向服务器发送请求后收到了204，那么浏览器页面不会发生更新 。
 *  206 Partial Content ：表示服务器已经完成了部分GET请求（客户端进行了范围请求）。

**3xx信息（重定向状态码）：需要进行附加操作以完成请求**

*  301 Moved Permanently ：永久重定向，表示请求的资源已经永久的搬到了其他位置，被分配了新的URI ，新的URI应该提示在响应报文的Location首部字段 。
 *  302 Found ：临时重定向，表示请求的资源临时搬到了其他位置 ，被配到到了新的URI 。
 *  303 See Other ：表示请求资源存在另一个URI，应使用GET定向获取请求资源
 *  304 Not Modified ：表示客户端发送附带条件的请求（GET方法请求报文中的If-Match，If-ModifiedSince，If-None-Match，If-Range，If-Unmodified-Since）时，条件不满足 返回304时，不包含任何响应主体 。
 *  307 Temporary Redirect ：临时重定向，与 302 的含义类似，但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法。

**4xx信息（客户端错误状态码）：客户端原因导致服务器无法处理请求**

*  400 Bad Request：表示请求报文存在语法错误或参数错误
 *  401 Unauthorized：表示发送的请求需要有HTTP认证信息或者是认证失败了
 *  403 Forbidden：请求被拒绝，服务器端没有必要给出拒绝的详细理由。
 *  404 Not Found：表示服务器找不到你请求的资源

**5xx信息（服务器错误状态码）：服务器处理请求出错**

*  500 Internal Server Error：服务器正在执行请求时发生错误。
 *  503 Service Unavilable：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求

### 2.6 HTTP 1.0/1.1/2.0的区别： ###

**HTTP 1.0存在的问题：**

>  *  不可进行长连接：长连接在HTTP 1.0中默认关闭，即每次请求都会发起一次TCP连接。创建一个TCP连接是需要经过三次握手的,有一定的开销，如果每次通讯都要重新建立连接的话，对性能有影响。因此最好能维持一个长连接，可以用个长连接来发多个请求。
>  *  线头阻塞：请求队列的第一个请求因为服务器正忙（或请求格式问题等其他原因），导致后面的请求被阻塞。

**HTTP 1.1的改进：**

>  *  长连接默认开启：在HTTP报文首部（header）中的connection字段进行控制，同时在HTTP 1.1实现了长连接后，HTTP 1.0也支持了长连接，但是默认为关闭状态
>  *  节约带宽：
>     
>      *  HTTP 1.1支持只发送header信息，即不携带body，只有当服务器返回100时，才将body发送，否则就不发送body了，节约了带宽。
>      *  支持仅发送部分请求内容，这样当客户端已经有一部分的资源后，只需要跟服务器请求另外的部分资源即可，而不需要进行整体资源的下载，这是**支持文件断点续传**的基础。
>  *  缓存优化：在HTTP/1.0中，使用Expire头域来判断资源的fresh或stale，并使用条件请求（conditional request）来判断资源是否仍有效。在HTTP 1. 1中则在首部增加了更多的字段，实现了更为丰富的缓存功能，例如：Cache-Control、Accept-Charset等。
>  *  Host字段：HTTP1.0是没有host域的，HTTP1.1才支持这个参数，也就是说在HTTP 1.1可以让web server上的多个虚拟站点共享同一个ip和端口。

**HTTP1.1存在的问题**

> 虽然HTTP 1.1通过默认开启长连接解决了多次连接的问题，但是仍然存在以下问题：
> 
>  *  串行的文件传输：当请求a文件时，b文件只能等待，等待a连接到服务器、服务器处理文件、服务器返回文件，这三个步骤。我们假设这三步用时都是1秒，那么a文件用时为3秒，b文件传输完成用时为6秒，依此类推。（注：此项计算有一个前提条件，就是浏览器和服务器是单通道传输）
>  *  连接数过多：我们假设服务器设置了最大并发数为300，因为浏览器限制，浏览器发起的最大请求数为6，也就是服务器能承载的最高并发为50，当第51个人访问时，就需要等待前面某个请求处理完成。

**HTTP 2.0的改进：**

>  *  多路复用：HTTP 2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP 1.1大了好几个数量级。同时，因为TCP连接有一个预热和保护的过程（拥塞控制），因此对应瞬时并发的连接，服务器的响应就会变慢。所以最好能使用一个建立好的连接，并且这个连接可以支持瞬时并发的请求。
>  *  HTTP 2.0采用二进制格式而非文本格式。
>  *  数据压缩：HTTP1.1不支持header数据的压缩，HTTP 2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。
>  *  服务器推送（Server Push）：当我们对支持HTTP 2.0的web server请求数据的时候，服务器可以将一些客户端需要的静态资源等一起推送到客户端，免得客户端再次创建连接发送请求到服务器端获取。

### 2.7 HTTP 转发和重定向 ###

重定向特点：两次请求，浏览器地址发生变化，可以访问自己 web 之外的资源，传输的数据会丢失。  
请求转发特点：一次请求，浏览器地址不变，访问的是自己本身的 web 资源，传输的数据不会丢失。

**本质区别：转发是服务器行为，重定向是客户端行为。**

### 2.8 HTTPS ###

**HTTP 存在的问题：**

>  *  通信使用明文不加密，内容可能被窃听
>  *  不验证通信方身份，可能遭到伪装
>  *  无法验证报文完整性，可能被篡改

HTTPS（Hypertext Transfer Protocol over Secure Socket Layer），通过 HTTP 下加入 SSL 层，**实现了内容加密、身份认证、数据完整性校验**，简而言之就是HTTP 的安全版，其所用的端口号是 443。

SSL/TSL 层：安全套接层(secure sockets layer)；TLS是SSL的继任者，叫传输层安全。

> 在SSL层又包含了两种认证方式：
> 
>  *  单向认证：只有一个对象校验对端的证书合法性，通常是客户端保存着服务端的证书并信任该证书即可。
>  *  双向认证：相互校验，服务器需要校验每个client,client也需要校验服务器，双向认证一般企业应用对接。
> 
> 所以一般HTTPS 采用的就是单向验证，即只需要验证服务端。

**HTTPS请求过程：**

请求的流程图为：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 1]

> 1.  浏览器发起往服务器的 443 端口发起请求，请求携带了浏览器支持的加密算法和哈希算法。
> 2.  服务器收到请求，选择浏览器支持的加密算法和哈希算法。
> 3.  服务器将数字证书返回给浏览器(这里的数字证书可以是向某个可靠机构申请的，也可以是自制的)
> 4.  浏览器进入数字证书认证环节，这一部分是浏览器内置的 TSL 完成的：
>     
>     1.  首先浏览器会从内置的证书列表中索引，找到服务器下发证书对应的机构，如果没有找到，此时就会提示用户该证书是不是由权威机构颁发，是不可信任的。如果查到了对应的机构，则取出该机构颁发的公钥。
>     2.  用机构的证书公钥解密得到证书的内容和证书签名，内容包括网站的网址、网站的公钥、证书的有效期等：浏览器会先验证证书签名的合法性。签名通过后，浏览器验证证书记录的网址是否和当前网址是一致的，不一致会提示用户。如果网址一致会检查证书有效期，证书过期了也会提示用户。这些都通过认证时，浏览器就可以安全使用证书中的网站公钥了。
>     3.  浏览器生成一个随机数 R，并使用网站公钥对 R 进行加密。
> 5.  浏览器将加密的 R 传送给服务器。
> 6.  服务器用自己的私钥解密得到 R。
> 7.  服务器以 R 为密钥使用了对称加密算法加密网页内容并传输给浏览器。
> 8.  浏览器以 R 为密钥使用之前约定好的解密算法获取网页内容。

所以HTTPS 在整个过程中使用了：**非对称加密（证书请求和验证阶段）+散列（证书请求和验证阶段）+对称加密（通信阶段）**

### 2.9 cookie、session、localStorage、sessionStorage区别 ###

<table> 
 <thead> 
  <tr> 
   <th>特性</th> 
   <th>Cookie</th> 
   <th>localStorage</th> 
   <th>sessionStorage</th> 
   <th>session</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>数据的生命期</td> 
   <td>一般由服务器生成，可设置失效时间。如果在浏览器端生成Cookie，默认是关闭浏览器后失效</td> 
   <td>除非被清除，否则永久保存</td> 
   <td>仅在当前会话下有效，关闭页面或浏览器后被清除</td> 
   <td>当用户访问服务器时，由服务器生成</td> 
  </tr> 
  <tr> 
   <td>存放数据大小</td> 
   <td>4K左右</td> 
   <td>一般为5MB</td> 
   <td>一般为5MB</td> 
   <td>一般为1024k</td> 
  </tr> 
  <tr> 
   <td>与服务器端通信</td> 
   <td>每次都会携带在HTTP头中，如果使用cookie保存过多数据会带来性能问题</td> 
   <td>仅在客户端（即浏览器）中保存，不参与和服务器的通信</td> 
   <td>仅在客户端（即浏览器）中保存，不参与和服务器的通信</td> 
   <td>保存在服务器端</td> 
  </tr> 
  <tr> 
   <td>易用性</td> 
   <td>攻击者可以分析存放在本地的cookie并进行cookie欺骗</td> 
   <td>和cookie一样具有安全问题</td> 
   <td>和cookie一样具有安全问题</td> 
   <td>访问增多时，会占用服务器的资源</td> 
  </tr> 
 </tbody> 
</table>

## 3. TCP/UDP ##

首先要明确TCP/UDP和TCP/IP的区别：**TCP/IP并不是某一个协议**，而是一个协议栈，与OSI的七层协议是对应的，里面包含了很多个协议，可以主要分为以下五层：应用层、传输层、网络层、数据链路层、物理层。而TCP/UDP则是分别指运输层中的两个协议：TCP、UDP。

### 3.1 TCP 报文格式 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 2]

其中比较重要的几个字段为：

（1）序号：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。 （2）确认号：Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。

（3）标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，在三次握手中建立连接时出现。

>  *  URG：紧急指针（urgent pointer）有效。
>  *  ACK：确认序号有效。
>  *  PSH：接收方应该尽快将这个报文交给应用层。
>  *  RST：重置连接。
>  *  SYN：发起一个新连接。
>  *  FIN：释放一个连接。

### 3.2 TCP 三次握手/四次挥手 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 3]

**握手过程如下：**

> 1.  假设A是客户端，B是服务端。A首先向B发出连接请求报文段，这个时候首部中的同步位SYN=1，同时选择一个初始的序号x。**此时SYN报文段不能携带数据（但需要消耗掉一个序号）**。此时A进入到SYN\_SENT(同步已发送)状态。
> 2.  B受到连接请求报文，同意建立连接，向A发出确认。确认报文中，SYN和ACK都置1，确认号是x+1,与此同时，自己选择一个初始序号y,这个报文也不能携带数据。此时B进入SYN\_RCVD（同步收到）状态。
> 3.  A收到B的确认后，还要给B确认。这时可以携带数据（如果不携带就不消耗序号），A进入到ESTABLISHED（已建立连接）状态。这就是三次握手的过程。
> 4.  B接收到了A的确认后，也进入了ESTABLISHED（已建立连接）状态。

**1. 为什么是三次握手，而不是两次握手呢？**

> 假设出现了这样的一种状况：当A发送了第一个报文段1后，但因为网络阻塞，B并没有收到报文，A认为报文段丢失了，就重传了报文段2，B成功的收到了报文段2并建立了连接，数据传输完毕后，关闭了连接。但是此时报文段1因为阻塞才到达B，B认为是A重新发起了一次连接请求，会向A进行确认，并同意建立连接，假设不采取第三次握手，那么此时的连接就已经建立完毕，但是A收到确认帧后因为自己并没有要求建立连接，就会不予理会，但是B却一直连接着，就会造成资源的浪费。

**2. TCP建立连接时，初始序号（seq）为什么用随机值？**

> 目前对tcp会话的攻击主要分为两种中间人攻击和注入式攻击。前者是改变通讯双方的通信过程，接管整个tcp会话；后者是不改变通信双方的通信，只是在会话中插入一些伪装ip的Tcp包，这就要解决对接收序列号的预测这个技术难题，这个序列号预测也是最大的一个难点，所以从安全的角度来说，tcp序列号初始值越趋近于随机越好，算法越复杂越好。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 4]

**四次挥手过程：**

> 1.  现在A和B都处于ESTABLISHED状态，A的应用进程向其TCP发出连接释放报文段，主动关闭TCP连接。A进入FIN\_WAIT1（终止等待1）状态。
> 2.  B确认，B进入CLOSE\_WAIT(关闭等待)状态。此时TCP处于半关闭状态(不在发送数据，但仍可以接收数据)，如果B仍要发送数据，A仍然接收。
> 3.  A收到B的确认后，就进入FIN\_WAIT2（终止等待2）状态，等待B发出连接释放报文。 如果B已经没有向A发送的数据，则B发送请求释放报文，B进入LAST\_ACK（最后确认）阶段，等待A的确认。
> 4.  A在收到B的请求后，要发出确认，然后进入TIME\_WAIT（时间等待）状态。此时，连接还未释放，必须等待时间等待计时器设定的时间的2MSL后，A才进入CLOSED状态。

**1. 为什么TIME-WAIT状态必须等待2MSL呢？**

> 1.  为了保证A发送的最后一个ACK报文段能够到达B：因为这个ACK报文可能会丢失，所以处在LAST-ACK状态的B收不到最后的ACK报文，就回重传FIN+ACK的报文段。A就能在2MSL时间内收到这个重传的报文段，并重新发送ACK报文段，并重置定时器。
> 2.  使本连接产生的所有报文段从网络中消失，这样在下一个新的连接中不会出现这种旧的连接请求报文段。

**2. 为什么建立连接是三次握手，而关闭连接是四次挥手？**

> 因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

### 3.3 TCP 流量控制 ###

TCP 进行拥塞控制的算法有四种：**慢开始、拥塞避免、快重传、快恢复。**

**慢开始**：当主机开始发送数据时，如果立即所大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。因此，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。如图所示，每成功接收一次，就将cwnd扩大一倍：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 5]  
为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量（如何设置ssthresh）。慢开始门限ssthresh的用法如下：

> 当 cwnd < ssthresh 时，使用上述的慢开始算法。
> 
> 当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
> 
> 当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法。

**拥塞避免**：让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍，这样拥塞窗口cwnd按线性规律缓慢增长。

所以，无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。所以最终**慢开始+拥塞避免**的算法实现图为：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 6]  
**快重传**：首先要求接收方每收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时才进行捎带确认。原理图为：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 7]

**快恢复**：当网络发生拥塞的时候，ssthresh将降为原来的一半，cwnd也降为一半，然后开始执行拥塞避免，而不是像慢开始一样，从1开始。

**快重传+快恢复**的原理图如图所示：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 8]

### 3.4 TCP 流量控制 ###

TCP就是通过**滑动窗口和回退N帧协议**来实现流量控制，所谓的流量控制，就是让发送方的放松速率不要太快，要让接收方来得及接收。

窗口是用来暂时存放字节流。发送方和接收方各维护一个窗口，接收方通过TCP报文段中的窗口字段告诉发送方自己的窗口大小，发送方需要根据接收方的窗口大小来设置自己的窗口。如果窗口大小为0，则代表对方拒绝接受消息，发送方就需要暂停数据的发送。

发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。例如：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 9]

接收方告诉发送方，建议滑动窗口为6，（如果超过6，就会溢出缓冲区），所以发送方可以一次最多可发送6个数据帧，假设已经发送了4,5,6，但是没收到确认的ACK，7,8,9则等待发送，如果此时发送端收到4号ACK，则窗口向右收缩，此时窗口就“滑动”了。

回退N帧协议：发送方一次发送比如说10个帧，前两个针都返回了对应的ACK，数据帧2出现了错误，这时发送方被迫重新发送2-8这七个帧，这就是回退N帧协议。但是如果接收方已经接收到了3-8帧，只是丢失了2帧，全部重传太浪费网络条件了，所以有时候会选择重传丢失的的帧，这就是选择重传协议。

### 3.5 UDP 协议 ###

UDP的主要特点为：

*  UDP是**无连接的**，即发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延；
 *  UDP使用**尽最大努力交付**，即不保证可靠交付，因此主机不需要维持复杂的连接状态表；
 *  UDP是**面向报文**的，即UDP对于应用层交下来的报文，仅添加首部后就交给了IP层；
 *  UDP**没有拥塞控制**：即当网络出现拥塞的时候，源主机的发送速率也不会降低，这恰恰能满足一些需要以恒定速率发送数据的应用。
 *  UDP**支持一对一、一对多、多对一和多对多的相互通信**；
 *  UDP**首部开销小**：只有8个字节，比TCP的20个字节短。

### 3.6 TCP和UDP的区别 ###

1.  UDP最大长度为512字节，TCP允许超过512字节；
2.  TCP通过拥塞控制、超时重传、确认机制等机制是可靠连接，UDP是不可靠的；
3.  TCP面向字节流，UDP面向报文；
4.  TCP是面向连接的，所以实现的是一对一通信，UPD是无连接的，所以可以实现一对多、多对多的通信；

## 4. IP协议 ##

IP协议是TCP/IP体系中最重要的协议之一，目前主要研究的IP协议有IPv4和IPv6（v代表的是版本号）。同时与IP协议配套使用的还有三个协议：

*  地址解析协议ARP
 *  网际控制报文协议ICMP
 *  网际组管理协议IGMP
 *  逆地址解析协议RARP(已被淘汰，不再使用)

具体的关系如下图所示:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 10]

### 4.1 地址解析协议ARP ###

首先我们在解释ARP协议之前，我们先弄懂两个概念：IP地址和硬件地址。

> **IP地址：** 网络层和以上各层使用的地址，是一种逻辑地址
> 
> **物理地址**：物理地址是数据链路层和物理层使用的地址

ARP 协议就是通过在主机的ARP的告诉缓存中存放一个IP地址到硬件地址的映射表，从而实现IP到硬件地址的解析。但需要注意的是，ARP协议解决的是**同一个局域网上**的主机或者路由器的IP地址到硬件地址的解析问题。

### 4.2 网际控制报文协议ICMP ###

ICMP是为了更有效地转发IP数据报和提高交付成功的机会，允许主机或路由器报告差错情况和提供有关异常情况的报告数据。**但需要注意的是，ICMP并不是高层协议，而是封装在IP数据报中，作为数据的一部分**。

ICMP报文可分为：**ICMP差错报告报文**和**ICMP询问报文**。

ICMP差错报文又可以分为四种：

*  **终点不可达**：路由器或者主机不能交付数据。
 *  **超时**：当路由器收到生存时间为0的数据报时，除了丢弃该报文，还需要像源节点发送超时报文，代表在预定时间内不可达。
 *  **参数问题**：当路由器或者主机收到的数据报的首部字段不正确时，就丢弃该报文，并向源节点发送参数问题报文。
 *  **重定向**：路由器或者将重定向的路由发给主机，让主机下次报文发给更优的路径。

ICMP询问报文可分为：

*  **回送请求和回答**：由源主机向目的主机发出的询问，目的主机在接收到该报文后需要向源主机发送ICMP回送回答报文。这种问询用来测试目标主机是否为可达状态并了解有关状态。
 *  **时间戳请求和回答**：由源主机向目的主机请求回答当前的日期和时间，这种问询主要用于时钟同步和时间测量。

**ICMP报文的重要应用：**

PING命令：用来测试两台主机之间的连通性。PING命令使用了ICMP的回送请求和回送回答报文，是应用层直接使用网络层的一个例子，他没有经过传输层的TCP或者UDP。

### 4.3 网际组管理协议IGMP ###

IGMP 在TCP/IP中负责局域网IP多播组成员管理的协议。用来在多播路由器与其局域网中的主机建立、维护多播组成员关系（组播路由器之间的组成员信息建立、维护使用组播路由协议）。

### 4.4 IPv6 ###

IPv6与IPv4相比，最主要的改进为：

1.  更大的地址空间：将地址扩大为原来的4倍（128位）
2.  地址层次更加丰富：地址空间更大，所以层次划分可以更多样
3.  灵活的首部格式：IPv6定义了许多可选的扩展首部，提高路由器的处理效率
4.  允许协议进行扩充：允许后期对于协议的改进，具有更好的灵活性
5.  支持资源的预分配

### 4.5 路由选择协议 ###

目前互联网的路由选择协议可分为：

*  **内部网关协议IGP**：具体的协议有很多，主要的是**RIP和OSPF**等；
    
     *  RIP：是一种分布式的基于距离向量的路由选择协议，是互联网的标准协议，其最大优点就是实现简单。但当网络出现故障时，传播时间也往往需要更长的时间。
     *  OSPF：开放最短路径优先。OSPF并不使用UDP而是直接使用IP数据报传送。与RIP明显的不同是，OSPF虽然原理简单，却难以实现。
 *  **外部网关协议EGP**：主要是BGP。

## 5. Web 安全 ##

### 5.1 XSS攻击 ###

XSS：跨站脚本攻击（Cross Site Scripting），指攻击者在网页中嵌入恶意脚本程序。

解决方案：

*  过滤或者转义特殊字符
 *  指定 HTTP 的 Content-Type

### 5.2 CRSF攻击 ###

CRSF：指通过伪装成受信任用户的进行访问。

解决方案：

*  验证Referer字段
 *  使用Token作为身份验证

XSS和CRSF的区别：

> XSS：利用的是用户对指定网站的信任，
> 
> CSRF：利用的是网站对用户网页浏览器的信任。

### 5.3 SQL注入 ###

SQL注入：通过sql命令伪装成正常的http请求参数，传递到服务器端，服务器执行sql命令造成对数据库进行攻击

解决方案：

*  使用预编译语句(PreparedStatement)
 *  使用orm框架可以对参数进行转义
 *  数据库敏感数据加密存储
 *

### 5.4 DDOS攻击 ###

DDOS：分布式拒绝服务攻击（Distributed Denial of Service），简单说就是发送大量请求是使服务器瘫痪。

解决方案：

*  最直接的方法增加带宽。
 *  云服务提供商有自己的一套完整DDoS解决方案，并且能提供丰富的带宽资源

## 联系作者 ##

有关转载、错误指正、问题咨询等事宜请扫码关注个人公众号进行联系，更有大量视频学习资源分享 ![70][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70]: /images/20220217/8721f908cff6471aa8e622d2a2d1b86e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 1]: /images/20220217/ef14e6e5f6594817aa67f2e3a5b2232d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 2]: /images/20220217/6476b32af923467f80f16d1ebbd1a56a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 3]: /images/20220217/ebe4b803915a45e5ac4bf83650155b9f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 4]: /images/20220217/203348b4548c409da54a46b3cf893f6b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 5]: /images/20220217/bb32dc90c933404cb61ea83409842625.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 6]: /images/20220217/10fd75a9a58c46bcbb9006d7030267d0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 7]: /images/20220217/35bff0788907492d9fe785481f3993fa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 8]: /images/20220217/34072abfe8df4cb99131d8107276c564.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 9]: /images/20220217/dfffd63e41ee40d8b3c71ef1b73f2ca8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3ODg4MDMx_size_16_color_FFFFFF_t_70 10]: /images/20220217/dae6e813f704487d8f6e0e1c771dc482.png
[70]: /images/20220217/1f5d5822a53942b7be7c58be62184886.png