计算机网络面试真题总结（一）

文章收录在网站：http://hardyfish.top/
文章收录在网站：http://hardyfish.top/
文章收录在网站：http://hardyfish.top/
文章收录在网站：http://hardyfish.top/

HTTP 哪些常用的状态码及使用场景？
   状态码分类
  

• 1xx：表示目前是协议的中间状态，还需要后续哀求
  
• 2xx：表示哀求成功
  
• 3xx：表示重定向状态，需要重新哀求
  
• 4xx：表示哀求报文错误
  
• 5xx：服务器端错误
  

  常用状态码
  

• 101：切换哀求协议，从 HTTP 切换到 WebSocket
  
• 200：哀求成功，有相应体
  
• 301：永久重定向：会缓存
  
• 302：临时重定向：不会缓存
  
• 304：协商缓存命中
  
• 403：服务器禁止访问
  
• 404：资源未找到
  
• 400：哀求错误
  
• 500：服务器端错误
  
• 503：服务器繁忙
  

  HTTP状态码301和302的区别
   301重定向（301 Move Permanently），指页面永久性转移，表示为资源或页面永久性地转移到了另一个位置。
  301是HTTP协议中的一种状态码，当用户或搜索引擎向服务器发出浏览哀求时
  

• 服务器返回的HTTP数据流中头信息（header）中包含状态码 301 ，表示该资源已经永久改变了位置。
  

  301与302的区别
  

• 301重定向是页面永久性转移
  
  
  
  • 搜索引擎在抓取新内容的同时也将旧的网址替换成重定向之后的网址
    
  
  
• 302重定向是页面暂时性转移
  
  
  
  • 搜索引擎会抓取新的内容而生存旧的网址并认为新的网址只是暂时的。
    
  
  

  说一说三次握手
   第一次握手：
  

• 客户端给服务器发送一个 SYN 报文。
  

  第二次握手：
  

• 服务器收到 SYN 报文之后，会应答一个 SYN+ACK 报文。
  

  第三次握手：
  

• 客户端收到 SYN+ACK 报文之后，会回应一个 ACK 报文。
  

  服务器收到 ACK 报文之后，三次握手建立完成。
  作用是为了确认双方的接收与发送本领是否正常。
  三次握手的作用
  

• 确认双方的担当本领、发送本领是否正常。
  
• 指定自己的初始化序列号，为后面的可靠传送做预备。
  

  什么是半连接队列
  

• 服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接
  
• 服务器会把此种状态下哀求连接放在一个队列里，我们把这种队列称之为半连接队列。
  
  
  
  • 当然另有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。
    
    
    
    • 如果队列满了就有可能会出现丢包征象。
      
    
    
  
  

  三次握手过程中可以携带数据吗
   第三次握手的时间，是可以携带数据的。
  

• 也就是说，第一次、第二次握手不可以携带数据，而第三次握手是可以携带数据的。
  

  假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器
  

• 那他每次都在第一次握手中的 SYN 报文中放入大量的数据
  
• 因为攻击者根本就不理服务器的接收、发送本领是否正常，然后疯狂着重复发 SYN 报文的话
  
  
  
  • 这会让服务器花费很多时间、内存空间来接收这些报文。
    
  • 也就是说，第一次握手可以放数据的话，此中一个简朴的缘故原由就是会让服务器更加轻易受到攻击了。
    
  
  

  而对于第三次的话，此时客户端已经处于 established 状态
  

• 也就是说，对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送本领是正常的了
  
  
  
  • 所以能携带数据页没啥毛病。
    
  
  

  说一说四次挥手
   第一次挥手：
  

• 客户端发送一个 FIN 报文，报文中会指定一个序列号。
  
  
  
  • 此时客户端处于FIN_WAIT1状态。
    
    
    
    • （相当于客户端告诉服务端，我想断开链接了）
      
    
    
  
  

  第二次挥手：
  

• 服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值
  
  
  
  • 表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT状态。
    
    
    
    • （相当于，服务端告诉客户端，好的，我收到你的断开哀求了）
      
    
    
  
  

  第三次挥手：
  

• 如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。
  
  
  
  • 此时服务端处于 LAST_ACK 的状态。
    
  
  

  第四次挥手：
  

• 客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值
  
  
  
  • 此时客户端处于 TIME_WAIT 状态。
    
  • 需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态
    
  
  

  服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。
  为什么客户端发送 ACK 之后不直接关闭，而是要等一阵子才关闭。
  

• 要确保服务器是否已经收到了我们的 ACK 报文，如果没有收到的话，服务器会重新发 FIN 报文给客户端
  
• 客户端再次收到 FIN 报文之后，就知道之前的 ACK 报文丢失了，然后再次发送 ACK 报文。
  

  至于 TIME_WAIT 持续的时间至少是一个报文的往返时间。
  

• 一般会设置一个计时，如果过了这个计时没有再次收到 FIN 报文
  
  
  
  • 则代表对方成功就是 ACK 报文，此时处于 CLOSED 状态。
    
  
  

  为什么 TIME-WAIT 状态必须等候 2MSL 的时间呢？
   为了保证 A 发送的最后一个 ACK 报文段能够到达 B。
  

• A 发送的 ACK 报文段有可能丢失，因而使处在 LAST-ACK 状态的 B 收不到对方已发送的 FIN + ACK 报文段简直认。
  
  
  
  • 这时 B 会超时重传这个 FIN+ACK 报文段
    
    
    
    • 而 A 就能在 2MSL 时间内（超时 + 1MSL 传输）收到这个重传的 FIN+ACK 报文段。
      
    • 接着 A 重传一次 ACK 报文确认，并且重新启动 2MSL 计时器。
      
    
    
  
  

  最后，A 和 B 都正常进入到 CLOSED 状态。如果 A 在 TIME-WAIT 状态不等候一段时间
  

• 而是在发送完 ACK 报文段后立即释放连接，那么就无法收到 B 重传的 FIN + ACK 报文段
  
• 因而也不会再发送一次确认报文段，如许，B 就无法按照正常步骤进入 CLOSED 状态。
  

  防止已失效的连接哀求报文段出现在本连接中。
  

• A 在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的全部报文段都从网络中消失。
  
  
  
  • 如许就可以使下一个连接中不会出现这种旧的连接哀求报文段。
    
  
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。