测试秋招八股文集锦——经典网络篇

一、前言：激动的心颤抖的手

测试秋招八股文集锦之信心鼓励篇发出3天时间内，被收藏124次，浏览1.8***丝也由178涨到了237，更激动的是俺红名啦！！！有点受宠若惊。
信心鼓励篇不知道有没有鼓励到你们，反正是鼓励到我自己更有动力更新文章了，哈哈哈哈哈哈哈哈哈哈~希望能真的帮助到求职的朋友们！！

二、经典网络题目录

1. get和post分别是什么？哪个更高效？区别是什么？

2. HTTP和HTTPS的区别

3. HTTP协议和Socket区别，哪个协议更高效？

4. TCP的三次握手、四次挥手

5. TCP和UDP的区别

6. 输入URL到显示网页发生了什么

7. OSI七层协议及每层作用

8. cookie和session的区别

9. DNS是做什么的？工作原理是什么？

10. SYN洪泛攻击如何解决？

11. 什么是IP地址和MAC地址？为啥有了IP地址还需要MAC地址

12. IP地址与MAC地址的区别？

三、经典网络题目解答

3.1 get和post分别是什么？哪个更高效？区别是什么？

3.1.1 get和post分别是什么？

GET和POST都是HTTP协议中的两种发送请求的方法，由于HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP。GET和POST能做的事情是一样一样的。如果给GET加上request body，活着给POST带上url参数，技术上是完全行的通的。也就是说，GET和POST在本质上没什么区别。 但是如果真的一点区别都没有，那么这个问题也就不存在了，所以，两者之间最重大的区别就是：

GET产生一个TCP数据包；POST产生两个TCP数据包。

3.1.2 哪个更高效？

GET比POST更高效。具体点说来就是：对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。这样看起来，因为POST需要两步，时间上消耗的要多一点，所以GET比POST更有效。

3.1.3 是否可用get替换post来优化网站性能？

不可以。原因如下：

原因一：get与post都有自己的语义，不能随便混用。

原因二：如果网络环境好的话，发一次包的时间和发两次包的时间差别基本可以无视。如果网络环境差的话，两次包的TCP在验证数据包完整性上，有非常大的优点。

原因三： 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。

注意：存放在请求行和请求体的不是方法, 而是请求/提交的数据， post和get方法都是在请求行中

3.1.4 get和post区别总结

精简版区别：Get / post区别：可缓存/不可；保留历史参数/不留；信息可见不安全/较安全；长度限制/不限制

区别详述：

• get数据明文存放在http请求行的url之后，post则是将提交的数据放在http请求报文的请求体中；（即GET参数通过URL传递，POST放在Request body中）

• POST比GET更安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。

• GET请求只能进行url编码，而POST支持多种编码方式。

• 受浏览器对url长度的限制，get传送数据量应不超过2KB。post传送数据量则一般无此限制；

• 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。

• get不能改变服务器的数据，一般用于从服务器获取数据，是幂等的；post可以改变服务器的数据，不是幂等的；

• get请求可以被浏览器主动缓存，下一次若传输数据相同，则优先返回缓存中的内容，以加快显示速度。post请求不会，除非手动设置一下；

• get请求参数会被完整地保存在浏览器历史记录中，post请求参数则不会保留。

3.2 HTTP和HTTPS的区别

1. HTTPS更安全以及所在层次不同

• HTTP协议运行在TCP之上，不提供身份认证和数据加密，所有数据都是以明文的形式传输的；通过抓包工具可以分析其信息内容。

• HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS运行在TCP之上。

• HTTPS协议是由SSL+HTTP协议构建的可进行加密传输和服务器端身份认证的网络协议。以对称加密的方式为传输的数据进行加密，用数字证书的方式提供服务器端的身份认证（但对称加密的密钥服务器方的整数进行了非对称加密），更为安全；

  2. HTTPS比HTTP需要耗费更多的资源，响应速度也更慢；
  3. HTTPS需要申请证书；

• HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。而常见的HTTP协议则不需要证书。

  4. HTTP和HTTPS是完全不同的连接方式，HTTP端口号是80，HTTPS的端口号是443

3.3 HTTP协议和Socket区别，哪个协议更高效？

（1）很多情况下，需要服务端主动向客户推送数据，保持客户端与服务端数据的实时与同步。但HTTP无法满足这一需求，Socket可以满足。

原因如下：

• HTTP连接使用“请求—响应”方式。不仅在请求时需要先建立连接，而且需要客户端向服务器发出请求后，服务端才能回复数据。

  若建立的是HTTP连接，则服务端需等到客户端发送一次请求后，才能将数据传回给客户端。

• 此时若双方建立的是Socket连接，服务器就可直接将数据传送给客户端；

  Socket连接一旦建立，通信双方即可相互发送数据内容，直到双方连接断开。

（2）创建Socket连接时，Socket可支持不同的传输层协议（TCP或UDP）。而HTTP只能基于TCP。

• Socket不仅能走TCP，还能走UDP。当使用TCP协议进行连接时，该Socket连接就是一个TCP连接。
• 同HTTP不同的是，HTTP只能基于TCP。

（3）Socket效率高，至少不用解析HTTP报文头部的一些字段。

3.4 TCP的三次握手、四次挥手

3.4.1 TCP的三次握手

首先发起连接的一端称为客户端，被动等待连接的一端称为服务器端。

• 客户端向服务器端发送一个同步报文，该TCP报文的首部控制位SYN=1，序列号随机，这里定为x。客户端发出报文后进入SYN-SENT状态；

• 服务器接收到报文进入到SYN-RECIVED状态，并返回一个确认报文给客户端，该TCP报文的首部控制位SYN=1,ACK=1,序列号为y(随机)，确认号为x+1

• 客户端接收到服务器端传来的确认报文后进入到established状态，并传送一个确认报文的确认给服务器，该报文的首部字段控制位ACK=1，序列号为x+1，确认号为y+1，此时可以携带数据部分。服务器端接收到该报文后进入到established状态

3.4.2 TCP的四次挥手

客户端和服务器端如果完成数据传送工作后，均可主动发起连接释放请求，这里假设客户端首先发起连接释放。

• 客户端发送FIN报文给服务器端，并进入到FIN-WAIT1阶段，该FIN报文包括首部字段控制位FIN=1，序列号seq=u，告诉服务器我已完成我的数据传输工作，你这边如果还有数据可以继续传送；
• 服务器收到该FIN报文之后进入close-wait阶段，并返回一个确认报文给客户端，该确认报文包括首部控制位ACK=1，seq=v，ack=u+1。客户端收到该确认报文后进入fin-wait2状态，关闭从客户端到服务器端的数据传送。服务器端仍可向客户端传送数据；
• 服务器端完成对客户端的数据传送工作之后，服务器端向客户端发送FIN报文，该报文结构包括FIN=1,ACK=1,序列号为w，确认号为u+1，并进入Last-ACK状态；
• 客户端接收到该FIN报文后，返回确认报文，该确认报文包括首部控制位ACK=1，序列号为u+1，确认号为w+1，并进入time-wait阶段，等待2MSL后确认服务器端收到ACK报文正常断开连接后，客户端关闭。服务器端收到该确认报文，进入closed状态。

3.4.3 等待2MSL的原因

确认服务器端是否正常收到了客户端最后发出的确认报文，如果服务器端没有收到的话，过1MSL（报文在网络中的最大存活时间）会重新再发送一次FIN报文给客户端，如果过了2MSL还没有收到新发的FIN报文的话，证明服务器端已经收到确认报文并正常关闭连接，客户端也可以关闭连接啦~

3.4.5 三次握手的原因

确保双方间的连接正常建立，如果只有两次握手的话可能会出现一些异常情况，比如：

• 客户端的SYN连接请求失效(或者发去时间太久,导致了超时重传的发生)，但是服务器端接收到了该SYN报文，如果不经过第三次握手的话服务器端就会错误地开启一个连接；
• 如果只有两次握手地话，服务器端返回给客户端的确认报文丢失，会导致客户端因为没有收到确认所以关闭了该连接，但服务器端此时已做好了连接准备，造成资源的浪费。

3.4.6 四次挥手的原因

因为建立连接时双方都处于closed状态，而释放连接时一方收到FIN报文但有可能还有数据要继续传输，不能马上释放连接，所以先返回一个确认报文，发送完数据后再断开连接。

3.5 TCP和UDP的区别

• TCP是面向连接的，UDP是无连接的。

面向连接意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据包之前必须先建立一个TCP连接。这一过程与打电话很相似，先拨号振铃，等待对方摘机说“喂”，然后才说明是谁。

• 数据传输形式不同。

TCP的数据传输以字节流的形式，TCP把数据看成一连串无结构的字节流。UDP的数据传输是以报文段的形式；

• TCP是全双工的可靠信道，UDP是不可靠信道。

TCP用检验和、标号、流量控制、拥塞控制、超时重传等机制保证TCP连接是可靠的，UDP则不保证可靠交付，只保证尽力交付；

通过TCP连接传输的数据不会丢失，没有重复，并且按顺序到达；

• 速率不同**。TCP所需资源多，传输速率慢，UDP所需资源少、传输速率快；**
• TCP只适用于一对一单播，UDP可用于广播通信；
• 适用场景不同。TCP适用于对可靠性要求较高的场景，比如文件的传输等，UDP适用于实时性要求较高的场景，比如微信视频通话等。
• 资料拓展：TCP连接可靠性原因：
  （a）为了确保消息传输的可靠性，TCP为每个分组提供序列号，并且还确保顺序接收发送到接收端实体的分组。
  （b） 然后，接收实体向成功接收的字节发回相应的确认（ACK）；
  （c）如果发送实体在合理的往返延迟（RTT）内没有收到确认，则将重新发送相应的数据（假设它丢失）

3.6 输入URL到显示网页发生了什么

• 浏览器解析URL对应的IP地址

DNS解析过程，浏览器缓存—>操作系统缓存—>本地DNS—>根据转发模式选择迭代还是递归查询

• 浏览器向服务器发送一个HTTP请求报文

传输层上建立TCP连接，网络层用到了IP协议(负责在网络层传输数据），还会用到RIP或者OSPF进行路由选择，然后用ARP协议解析IP地址对应的MAC地址，使得数据能够在数据链路层上进行传输（不应该是最后到物理层传输吗）。

HTTP请求方法有哪些（post/get/head/put/delete）

• 服务器请求处理并返回一个HTTP响应报文

HTTP响应报文的结构，状态码

• 服务器返回一个HTML响应，浏览器收到HTML响应并渲染界面

3.7 OSI七层协议及每层作用

• 物理层。通过媒介传输比特，确定机械及电气规范。
• 数据链路层。将比特组装成帧和点到点的传递。
• 网络层。负责数据包从源到宿的传递和网际互连。
• 传输层。提供端到端的可靠报文传递和错误恢复。
• 会话层。建立、管理和终止会话（绘画协议数据单元）。
• 表示层。对数据进行翻译、加密和压缩。
• 应用层。允许访问OSI环境的手段。

3.8 cookie和session的区别

3.8.1 了解cookie和session

首先它们都是用于给无连接的http提供身份认证的功能

• cookie是服务器在本机存放的小段文本，并随每一个请求发送至同一服务器。cookie分为会话cookie（不设置过期时间，关闭浏览器窗口cookie即失效，保存在内存中）和持久cookie（设置过期时间，关闭再打开浏览器cookie仍存在，直至达到过期时间）。类似于检查通行证（即请求报文中附带的cookie）来确定用户身份

• session则一般是利用session id实现的（session id是浏览器第一次发送请求时服务器自动生成的唯一标识，并返回给浏览器），cookie中携带该session id，客户端根据该session id将session检索出来。类似于在服务器上建立一个客户档案，客户来访时需要查询客户档案

3.8.2 Cookie和session区别——速记版本

• 客户端/服务器；
• 有限制/无限制；
• 直接查找篡改/加密存在服务器中；
• 关闭浏览器消失/存在于服务器一段时间，消耗资源；

3.8.3 Cookie和session区别——详细概括

• cookie是存放在客户端，用于记录用户信息的，比如自动填充用户名和密码；session是存放在服务器端的，用于记录用户的状态，比如购物车的实现。

• cookie不太安全，可以分析存放在本地的cookie进行cookie欺骗，（也可以用加密算法加密后进行存放），session存放于服务器的内存中，所以安全性高

• 单个cookie保存数据不能超过4k，session没有对存储数据量的限制

禁掉cookie的话session仍然可以使用，但是需要使用其他方法获取session id，比如在url后面或者以表单的形式提交给服务器端

3.9 DNS是做什么的？工作原理是什么？

3.9.1DNS过程

• 检查浏览器中缓存.
• 检查操作系统内缓存
• 请求本地域名服务器，递归查询
• 本地请求根服务器，迭代查询
• 找到ip后自己缓存

3.9.2 DNS作用

3.9.3 DNS的获取流程

那我就后续乖乖把剩下的几篇都更完，我睡觉觉啦，你们也要早点睡吖~~~