计算机网络校招面试题总结

梦里梦外; 2022-11-25 13:30 190阅读 0赞

### 文章目录 ###

*  HTTP
 *  TCP&UDP
 *  Session & Cookie
 *  三次握手、四次挥手
 *  模型
 *  安全问题
 *  其它

# HTTP #

1.**Http和Https的区别**

> Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份；Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。二者之间存在如下不同：

*  端口不同：Http与Http使用不同的连接方式，用的端口也不一样，前者是80，后者是443；
 *  资源消耗：和HTTP通信相比，Https通信会由于加减密处理消耗更多的CPU和内存资源；
 *  开销：Https通信需要证书，而证书一般需要向认证机构购买；

> Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。

1.  **简单介绍一下HTTP的长连接和短连接**  
    HTTP的长连接和短连接本质上是TCP长连接和短连接。HTTP属于应用层协议。

*  **短连接**:浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。
 *  **长连接**:当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接要客户端和服务端都支持长连接。

1.  **对称加密与非对称加密**  
    对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；而非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。

> 由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

1.  **GET与POST的区别**  
    GET与POST是我们常用的两种HTTP Method，二者之间的区别主要包括如下五个方面：

*  从功能上讲，GET一般用来从服务器上获取资源，POST一般用来更新服务器上的资源；
 *  从REST服务角度上说，GET是幂等的，即读取同一个资源，总是得到相同的数据，而POST不是幂等的，因为每次请求对资源的改变并不是相同的；进一步地，GET不会改变服务器上的资源，而POST会对服务器资源进行改变；
 *  从请求参数形式上看，GET请求的数据会附在URL之后，即将请求数据放置在HTTP报文的 请求头 中，以?分割URL和传输数据，参数之间以&相连。特别地，如果数据是英文字母/数字，原样发送；否则，会将其编码为 application/x-www-form-urlencoded MIME 字符串(如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII)；而POST请求会把提交的数据则放置在是HTTP请求报文的 请求体 中。
 *  就安全性而言，POST的安全性要比GET的安全性高，因为GET请求提交的数据将明文出现在URL上，而且POST请求参数则被包装到请求体中，相对更安全。
 *  从请求的大小看，GET请求的长度受限于浏览器或服务器对URL长度的限制，允许发送的数据量比较小，而POST请求则是没有大小限制的。

1.  **你对 HTTP 状态码有了解吗？**  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70]

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

1.  200 OK
2.  204 No Content ：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。
3.  206 Partial Content ：表示客户端进行了范围请求，响应报文包含由 Content-Range 指定范围的实体内容。

*  3XX 重定向

1.  301 Moved Permanently ：永久性重定向；
2.  302 Found ：临时性重定向；
3.  303 See Other ：和 302 有着相同的功能，但是 303 明确要求客户端应该采用 GET 方法获取资源。
4.  304 Not Modified ：如果请求报文首部包含一些条件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不满足条件，则服务器会返回 304 状态码。
5.  307 Temporary Redirect ：临时重定向，与 302 的含义类似，但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法。

*  4XX 客户端错误

1.  400 Bad Request ：请求报文中存在语法错误。
2.  401 Unauthorized ：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。
3.  403 Forbidden ：请求被拒绝。
4.  404 Not Found

*  5XX 服务器错误

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

6.**HTTP 状态码 301 和 302 代表的是什么？有什么区别？**

301，302 都是 HTTP 状态的编码，都代表着某个 URL 发生了转移。  
区别：

*  301 redirect: 301 代表永久性转移（Permanently Moved）
 *  302 redirect: 302 代表暂时性转移（Temporarily Moved）

1.  **HTTPS 的工作过程？**

*  客户端发送自己支持的加密规则给服务器，代表告诉服务器要进行连接了；
 *  服务器从中选出一套加密算法和 hash 算法以及自己的身份信息（地址等）以证书的形式发送给浏览器，证书中包含服务器信息，加密公钥，证书的办法机构；
 *  客户端收到网站的证书之后要做下面的事情：

1.  验证证书的合法性；
2.  如果验证通过证书，浏览器会生成一串随机数，并用证书中的公钥进行加密；
3.  用约定好的 hash 算法计算握手消息，然后用生成的密钥进行加密，然后一起发送给服务器。

*  服务器接收到客户端传送来的信息，要做下面的事情：

1.  用私钥解析出密码，用密码解析握手消息，验证 hash 值是否和浏览器发来的一致；
2.  使用密钥加密消息；

*  如果计算法 hash 值一致，握手成功。

1.  **谈下 HTTP 1.0 和 1.1、1.2 的主要变化？**

*  HTTP1.1 的主要变化：

1.  HTTP1.0 经过多年发展，在 1.1 提出了改进。首先是提出了长连接，HTTP 可以在一次 TCP 连接中不断发送请求。
2.  然后 HTTP1.1 支持只发送 header 而不发送 body。原因是先用 header 判断能否成功，再发数据，节约带宽，事实上，post 请求默认就是这样做的。
3.  HTTP1.1 的 host 字段。由于虚拟主机可以支持多个域名，所以一般将域名解析后得到 host。

*  HTTP2.0 的主要变化：

1.  HTTP2.0 支持多路复用，同一个连接可以并发处理多个请求，方法是把 HTTP数据包拆为多个帧，并发有序的发送，根据序号在另一端进行重组，而不需要一个个 HTTP请求顺序到达；
2.  HTTP2.0 支持服务端推送，就是服务端在 HTTP 请求到达后，除了返回数据之外，还推送了额外的内容给客户端；
3.  HTTP2.0 压缩了请求头，同时基本单位是二进制帧流，这样的数据占用空间更少；
4.  HTTP2.0 适用于 HTTPS 场景，因为其在 HTTP和 TCP 中间加了一层 SSL 层。

# TCP&UDP #

1.  **TCP协议如何来保证传输的可靠性**  
    TCP提供一种面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个TCP连接。在一个TCP连接中，仅有两方进行彼此通信；而字节流服务意味着两个应用程序通过TCP链接交换8bit字节构成的字节流，TCP不在字节流中插入记录标识符。

**对于可靠性，TCP通过以下方式进行保证：**

*  数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据；
 *  对失序数据包重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层；
 *  丢弃重复数据：对于重复数据，能够丢弃重复数据；
 *  应答机制：当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
 *  超时重发：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
 *  流量控制：TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。

1.  **滑动窗口**  
    位于传输层的TCP协议是面向连接的，可靠的传输协议，拥有着确认机制。理论上，每发一个数据包都会收到其对应的确认包，然后才可以继续发送数据。  
    在三次握手阶段，双方互相将自己的最大可接收的数据量告诉对方，也就是自己的数据接收缓冲池的大小。这样对方可以根据已发送的数据量来计算是否可以接着发送。在处理过程中，当接收缓冲池的大小发生变化时，要给对方发送更新窗口大小的通知，利用滑动窗口机制有效提高通信效率。
2.  **TCP与UDP的区别**

*  TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)协议属于传输层协议，它们之间的区别包括：
 *  TCP是面向连接的，UDP是无连接的；
 *  TCP是可靠的，UDP是不可靠的；
 *  TCP只支持点对点通信，UDP支持一对一、一对多、多对一、多对多的通信模式；
 *  TCP是面向字节流的，UDP是面向报文的；
 *  TCP有拥塞控制机制;UDP没有拥塞控制，适合媒体通信；
 *  TCP首部开销(20个字节)比UDP的首部开销(8个字节)要大；  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 1]

1.  **TCP的拥塞处理**

> 计算机网络中的带宽、交换结点中的缓存及处理机等都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏，这种情况就叫做拥塞。拥塞控制就是 防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。注意，拥塞控制和流量控制不同，前者是一个全局性的过程，而后者指点对点通信量的控制。拥塞控制的方法主要有以下四种：

*  **慢启动**：不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小;
 *  **拥塞避免**：拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍，这样拥塞窗口按线性规律缓慢增长。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 2]
 *  **快重传**：快重传要求接收方在收到一个 失序的报文段 后就立即发出 重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 3]
 *  **快恢复**:快重传配合使用的还有快恢复算法，当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半，但是接下去并不执行慢开始算法：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 4]

# Session & Cookie #

1.  **Session和Cookie对比**

*  实现机制：Session的实现常常依赖于Cookie机制，通过Cookie机制回传SessionID；
 *  大小限制：Cookie有大小限制并且浏览器对每个站点也有cookie的个数限制，Session没有大小限制，理论上只与服务器的内存大小有关；
 *  安全性：Cookie存在安全隐患，通过拦截或本地文件找得到cookie后可以进行攻击，而Session由于保存在服务器端，相对更加安全；
 *  服务器资源消耗：Session是保存在服务器端上会存在一段时间才会消失，如果session过多会增加服务器的压力。

# 三次握手、四次挥手 #

1.  **讲一讲对于三次握手的理解**  
    （我要和你建立链接，你真的要和我建立链接么，我真的要和你建立链接，成功）  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 5]

*  第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN\_SENT状态，等待Server确认。
 *  第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN\_RCVD状态。
 *  第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。

1.  **四次挥手**  
    （我要和你断开链接；好的，断吧。我也要和你断开链接；好的，断吧）

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 6]

*  第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN\_WAIT\_1状态。
 *  第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE\_WAIT状态。此时TCP链接处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收。
 *  第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST\_ACK状态。
 *  第四次挥手：Client收到FIN后，Client进入TIME\_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

1.  **为什么不能用两次握手进行连接？**  
    3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。  
    现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
2.  **为什么断开连接需要四次**  
    根据状态流程图，我们可以看出服务端响应断开连接的请求时，其ACK和FIN包并不是一起发送给客户端的，因为第一次由客户端->服务端的FIN信号表示的是客户端想要断开连接。服务端先给出ACK确认信号，表示已经收到FIN请求，然后当自己也可以结束的时候，再次发送FIN信号，所以需要挥手交互需要四次。
3.  **四次挥手主动方为什么需要等待2MSL**  
    主动关闭方在收到被动一方发出的FIN信号，会立马发送ACK确认信号，之后状态转变为TIME\_WAIT，等待2MSL后才会进入CLOSE状态。

> **MSL**表示最大报文生存周期，任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。主动关闭方需要等待2MSL是为了，防止最后一次ACK没有被正确的传给被动方，被动关闭方会再次发送第三次的FIN信号。

1.  **挥手为什么第二次跟第三次不能合并, 第二次和第三次之间的等待是什么?**  
    当服务器执行第二次挥手之后, 此时证明客户端不会再向服务端请求任何数据, 但是服务端可能还正在给客户端发送数据（可能是客户端上一次请求的资源还没有发送完毕），所以此时服务端会等待把之前未传输完的数据传输完毕之后再发送关闭请求。
2.  **什么是粘包？**  
    如果客户端连续不断的向服务端发送数据包时，服务端接收的数据会出现两个数据包粘在一起的情况。

*  TCP 是基于字节流的，虽然应用层和 TCP 传输层之间的数据交互是大小不等的数据块，但是 TCP 把这些数据块仅仅看成一连串无结构的字节流，没有边界；
 *  从 TCP 的帧结构也可以看出，在 TCP 的首部没有表示数据长度的字段。基于上面两点，在使用 TCP 传输数据时，才有粘包或者拆包现象发生的可能。一个数据包中包含了发送端发送的两个数据包的信息，这种现象即为粘包。
 *  接收端收到了两个数据包，但是这两个数据包要么是不完整的，要么就是多出来一块，这种情况即发生了拆包和粘包。拆包和粘包的问题导致接收端在处理的时候会非常困难，因为无法区分一个完整的数据包。

1.  **TCP 黏包是怎么产生的？**

*  **发送方产生粘包**  
    采用 TCP 协议传输数据的客户端与服务器经常是保持一个长连接的状态（一次连接发一次数据不存在粘包），双方在连接不断开的情况下，可以一直传输数据。但当发送的数据包过于的小时，那么 TCP 协议默认的会启用 Nagle 算法，将这些较小的数据包进行合并发送（缓冲区数据发送是一个堆压的过程）；这个合并过程就是在发送缓冲区中进行的，也就是说数据发送出来它已经是粘包的状态了。
 *  **接收方产生粘包**  
    接收方采用 TCP 协议接收数据时的过程是这样的：数据到接收方，从网络模型的下方传递至传输层，传输层的 TCP 协议处理是将其放置接收缓冲区，然后由应用层来主动获取（C 语言用 recv、read 等函数）；这时会出现一个问题，就是我们在程序中调用的读取数据函数不能及时的把缓冲区中的数据拿出来，而下一个数据又到来并有一部分放入的缓冲区末尾，等我们读取数据时就是一个粘包。（放数据的速度 > 应用层拿数据速度）

1.  **怎么解决拆包和粘包？**  
    分包机制一般有两个通用的解决方法：

*  特殊字符控制；
 *  在包头首都添加数据包的长度。  
    如果使用 netty 的话，就有专门的编码器和解码器解决拆包和粘包问题了。  
    tips：UDP 没有粘包问题，但是有丢包和乱序。不完整的包是不会有的，收到的都是完全正确的包。传送的数据单位协议是 UDP 报文或用户数据报，发送的时候既不合并，也不拆分。

1.  **TCP和UDP分别对应的常见应用层协议**

1). TCP对应的应用层协议

*  FTP：定义了文件传输协议，使用21端口。常说某某计算机开了FTP服务便是启动了文件传输服务。下载文件，上传主页，都要用到FTP服务。
 *  Telnet：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于DOS模式下的通信服务。如以前的BBS是-纯字符界面的，支持BBS的服务器将23端口打开，对外提供服务。
 *  SMTP：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置-中常看到有这么SMTP端口设置这个栏，服务器开放的是25号端口。
 *  POP3：它是和SMTP对应，POP3用于接收邮件。通常情况下，POP3协议所用的是110端口。也是说，只要你有相应的使用POP3协议的程序（例如Fo-xmail或Outlook），就可以不以Web方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是163邮箱就没有必要先进入网易网站，再进入自己的邮-箱来收信）。
 *  HTTP：从Web服务器传输超文本到本地浏览器的传送协议。  
    2). UDP对应的应用层协议
 *  DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。
 *  SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。
 *  TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口69上使用UDP服务。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 7]

1.  **TCP协议中的数据包分片与重组功能有了解吗？**  
    当TCP传输的数据包比较大时，在接收方会进行分片，在接收方进行数据包的重组。

*  发送方：  
    将数据包分为多个TCP头部+数据包的组合，TCP头部中存着不同的数据序号；之后将多个组合交由IP模块，统一添加IP头部和MAC头部，IP头部的ID号设为统一的。
 *  接收方：  
    IP模块具有分片重组的功能，如果接收到的包是经过分片的，那么IP模块会将它们还原成原始的包。  
    分片的包会在IP头部的标志字段中进行标记，当收到分片的包时，IP模块会将其暂时存在内部的内存空间中，然后等待IP头部中具有相同ID的包全部到达，因为同一个包的所有分片都具有相同的ID。此外，IP头部还有一个分片偏移量的字段，它表示当前分片在整个包中所处的位置。根据这些信息，在所有的分片全部收到之后，就可以将它们还原成原始的包。

> 解析：数据包的分片和重组里边还涉及到了MTU和MSS的概念，介绍如下：

*  MTU: Maxitum Transmission Unit 最大传输单元
 *  MSS: Maxitum Segment Size 最大分段大小，MSS就是TCP数据包每次能够传输的最大数据分段。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 8]

# 模型 #

1.  **谈下你对五层网络协议体系结构的理解？**  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 9]  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 10]

1). 物理层  
参考模型的最低层，也是OSI模型的第一层，实现了相邻计算机节点之间比特流的透明传送，并尽可能地屏蔽掉具体传输介质和物理设备的差异，使其上层(数据链路层)不必关心网络的具体传输介质。

2). 数据链路层（data link layer）  
接收来自物理层的位流形式的数据，并封装成帧，传送到上一层；同样，也将来自上层的数据帧，拆装为位流形式的数据转发到物理层。这一层在物理层提供的比特流的基础上，通过差错控制、流量控制方法，使有差错的物理线路变为无差错的数据链路，即提供可靠的通过物理介质传输数据的方法。  
3). 网络层  
将网络地址翻译成对应的物理地址，并通过路由选择算法为分组通过通信子网选择最适当的路径。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 11]  
4). 传输层（transport layer）  
在源端与目的端之间提供可靠的透明数据传输，使上层服务用户不必关系通信子网的实现细节。在协议栈中，传输层位于网络层之上，传输层协议为不同主机上运行的进程提供逻辑通信，而网络层协议为不同主机提供逻辑通信，如下图所示。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 12]  
实际上，网络层可以看作是传输层的一部分，其为传输层提供服务。但对于终端系统而言，网络层对它们而言是透明的，它们知道传输层的存在，也就是说，在逻辑上它们认为是传输层为它们提供了端对端的通信，这也是分层思想的妙处。  
5). 会话层（Session Layer）  
会话层是OSI模型的第五层，是用户应用程序和网络之间的接口，负责在网络中的两节点之间建立、维持和终止通信。  
6). 表示层（Presentation Layer）：数据的编码，压缩和解压缩，数据的加密和解密  
表示层是OSI模型的第六层，它对来自应用层的命令和数据进行解释，以确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。  
7). 应用层（Application layer）：为用户的应用进程提供网络通信服务

1.  **ARP 协议的工作原理？**  
    网络层的 ARP 协议完成了 IP 地址与物理地址的映射。首先，每台主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表，以表示 IP 地址和 MAC 地址的对应关系。当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP 列表中是否存在该 IP 地址对应的 MAC 地址：如果有，就直接将数据包发送到这个 MAC 地址；如果没有，就向本地网段发起一个 ARP 请求的广播包，查询此目的主机对应的 MAC 地址。  
    此 ARP 请求数据包里包括源主机的 IP 地址、硬件地址、以及目的主机的 IP 地址。网络中所有的主机收到这个 ARP 请求后，会检查数据包中的目的 IP 是否和自己的 IP 地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中，如果 ARP 表中已经存在该 IP 的信息，则将其覆盖，然后给源主机发送一个 ARP 响应数据包，告诉对方自己是它需要查找的 MAC 地址；源主机收到这个 ARP 响应数据包后，将得到的目的主机的 IP 地址和 MAC 地址添加到自己的 ARP 列表中，并利用此信息开始数据的传输。如果源主机一直没有收到 ARP 响应数据包，表示 ARP 查询失败。

# 安全问题 #

1.  **SQL注入**：  
    SQL注入就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

1). SQL注入攻击的总体思路

(1). 寻找到SQL注入的位置  
　　(2). 判断服务器类型和后台数据库类型  
　　(3). 针对不通的服务器和数据库特点进行SQL注入攻击

2). SQL注入攻击实例  
比如，在一个登录界面，要求输入用户名和密码，可以这样输入实现免帐号登录：

用户名： ‘or 1 = 1 --
    密 码：

用户一旦点击登录，如若没有做特殊处理，那么这个非法用户就很得意的登陆进去了。这是为什么呢?下面我们分析一下：从理论上说，后台认证程序中会有如下的SQL语句：String sql = “select \* from user\_table where username=’ “+userName+” ’ and password=’ “+password+” ‘”; 因此，当输入了上面的用户名和密码，上面的SQL语句变成：SELECT \* FROM user\_table WHERE username=’’or 1 = 1 – and password=’’。分析上述SQL语句我们知道，username=‘ or 1=1 这个语句一定会成功；然后后面加两个-，这意味着注释，它将后面的语句注释，让他们不起作用。这样，上述语句永远都能正确执行，用户轻易骗过系统，获取合法身份。  
2. **XSS攻击**  
　XSS是一种经常出现在web应用中的计算机安全漏洞，与SQL注入一起成为web中最主流的攻击方式。XSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些脚本代码嵌入到web页面中去，使别的用户访问都会执行相应的嵌入代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

*  原因解析  
    （1）主要原因：过于信任客户端提交的数据！  
    （2）解决办法：不信任任何客户端提交的数据，只要是客户端提交的数据就应该先进行相应的过滤处理然后方可进行下一步的操作。  
    （3）进一步分析细节：客户端提交的数据本来就是应用所需要的，但是恶意攻击者利用网站对客户端提交数据的信任，在数据中插入一些符号以及javascript代码，那么这些数据将会成为应用代码中的一部分了，那么攻击者就可以肆无忌惮地展开攻击啦，因此我们绝不可以信任任何客户端提交的数据！！！

# 其它 #

1.  **从输入网址到获得页面的过程**

*  浏览器查询 DNS，获取域名对应的IP地址:具体过程包括浏览器搜索自身的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询等。对于向本地DNS服务器进行查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析(此解析具有权威性)；如果要查询的域名不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析（此解析不具有权威性）。如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者迭代查询；
 *  浏览器获得域名对应的IP地址以后，浏览器向服务器请求建立链接，发起三次握手；
 *  TCP/IP链接建立起来后，浏览器向服务器发送HTTP请求；
 *  服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；
 *  浏览器解析并渲染视图，若遇到对js文件、css文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；
 *  浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。

1.  [**DNS解析过程**][DNS]
2.  **一个网络数据包包括哪些有了解吗？**  
    网络数据包一般包括头部和数据部分，在TCP协议中，要发送的数据经过TCP模块添加TCP头部；然后IP模块添加IP头部和MAC头部；然后在最前面加上报头/起始帧分界符以及末尾假如FCS（帧校验序列），这样就构成了一个完成的数据包。  
    ![在这里插入图片描述][20200810215238998.png]  
    在UDP协议中就是UDP头部，各个头部都有其固定的格式，TCP头部最小20个字节，UDP头部最小8个字节。

参考文章：  
[文章一][Link 1]  
[文章二][Link 2]  
[文章三][Link 3]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70]: /images/20221124/204f6b7ce2754478a65f59602a3b5d64.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 1]: /images/20221124/52ebfe19d2af4767b74c1cd6c1a5bd3c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 2]: /images/20221124/6fd6d9d6860c4d16821817eb221fc5e9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 3]: /images/20221124/a15447af1fb54e03bd082615fa57e613.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 4]: /images/20221124/01a07bcc6bf5473bbbe3344a77cf12b0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 5]: /images/20221124/0e3eb4e2d3314c7fa22b50e63e803ba4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 6]: /images/20221124/f1029a64b2274326a0e0ef9d46b39d4c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 7]: /images/20221124/33d4c288e07744bf939b55600f5c13a6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 8]: /images/20221124/adce60680ecc45168703818fe66d7f02.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 9]: /images/20221124/6a3e32500e4540b68c337e11d7c054b2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 10]: /images/20221124/9ee3915176dd4dcbad9e2d874998816c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 11]: /images/20221124/ce2ac48120744c6b8b6c639d19523185.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JvYl9tYW4_size_16_color_FFFFFF_t_70 12]: /images/20221124/76ba36d7e8ca4469959a38cae8f20699.png
[DNS]: https://blog.csdn.net/bob_man/article/details/105023043
[20200810215238998.png]: /images/20221124/464bedadb2a946c38281fa85dc9739f5.png
[Link 1]: https://zhuanlan.zhihu.com/p/158633588
[Link 2]: https://blog.csdn.net/pcwl1206/article/details/103959802
[Link 3]: https://blog.csdn.net/justloveyou_/article/details/78303617