一、前言：激动的心颤抖的手   测试秋招八股文集锦之信心鼓励篇发出3天时间内，被收藏124次，浏览1.8***丝也由178涨到了237，更激动的是俺红名啦！！！有点受宠若惊。 信心鼓励篇不知道有没有鼓励到你们，反正是鼓励到我自己更有动力更新文章了，哈哈哈哈哈哈哈哈哈哈~希望能真的帮助到求职的朋友们！！      二、经典网络题目录           get和post分别是什么？哪个更高效？区别是什么？              HTTP和HTTPS的区别              HTTP协议和Socket区别，哪个协议更高效？              TCP的三次握手、四次挥手              TCP和UDP的区别              输入URL到显示网页发生了什么              OSI七层协议及每层作用              cookie和session的区别              DNS是做什么的？工作原理是什么？              SYN洪泛攻击如何解决？              什么是IP地址和MAC地址？为啥有了IP地址还需要MAC地址              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的区别       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作用  DNS是应用层协议，事实上是为其他应用层协议工作的，包括不限于HTTP、SMTP以及FTP,用于将用户提供的主机名解析为IP地址。   3.9.3 DNS的获取流程           用户主机上运行着DNS的客户端，就是我们的PC机或者手机客户端运行着DNS客户端了。          浏览器将接收到url中抽取出域名字段，就是访问的主机名，并将这几名传送给DNS应用的客户端；          DNS客户端向DNS服务器端发送一份查询报文，报文中包含要访问的主机名字段（中间包含列缓存查询以及分布式DNS集群的工作）；          该DNS客户机最终会收到一份回答报文，其中包含该主机名对应的IP地址；          一旦该浏览器收到来自DNS的IP地址，就可以向该IP地址定位的HTTP服务器发起TCP连接。          3.10 SYN洪泛攻击如何解决？   攻击者伪装成客户端发送TCP的SYN报文, 当服务器返回ACK确认报文之后, 攻击者不再进行确认, 即不回复确认的确认报文, 这个连接就处于一个挂起的状态, 服务器收不到确认报文的话, 会启用超时重传机制, 重复发送ACK给攻击者  这样的话,如果攻击者开启大量这种TCP连接, 导致服务器端有很多个挂起的连接, 并且需要重复发送很多ACK给攻击者, 这样就会消耗服务器的内存 可能导致最后服务器死机, 无法正常工作     解决方法           降低SYN timeout时间 使得服务器在没收到确认报文后尽快释放半连接的占用          采用SYN cookie设置 给每一个请求连接的ip地址分配一个cookie,短时间内如果连续收到某个IP的重复的SYN报文,就认定收到了攻击,以后会自动丢弃该ip地址传送过来的包          3.11什么是IP地址和MAC地址？为啥有了IP地址还需要MAC地址            MAC地址是网络中每个设备都有的唯一网络标识，全世界唯一。          IP地址只是逻辑上的标识，任何人都能随意修改，因此不能具体标识一个用户，但MAC地址固化在网卡里，防止被盗用。          但是如果只用MAC地址的话，因为MAC地址无序杂乱，没有明显规则，难以查找。但是IP是分层的，类似通讯地址，可以根据其网络号找到子网再定义主机，逐级查找，每个设备需要存储的信息较少          3.12 MAC地址与IP地址的区别           长度不同，IP地址一般为32位（IPv6 128位），MAC地址则是48位          分配依据不同，IP地址分配基于网络拓扑，能够根据需要改动设备的IP地址，但是MAC地址的分配是基于制造商，在网卡中烧录好，一般不轻易改变          寻址协议层不同，IP地址应用于网络层，MAC地址应用于数据链路层（数据链路层基于MAC地址转发数据帧，数据链路层的交换机根据其MAC地址记录表中的MAC地址及其对应的端口，将其发送到MAC地址对应的端口，否则广播；网络层则根据IP地址转发报文，路由器根据路由表转发到对应端口，否则发送默认路由）          四、写在最后   写晚这篇文章已经凌晨0:08了，每晚11:30之前睡觉的flag又倒了，哈哈哈哈哈哈哈~~~在写文章的过程中，手机还在陆陆续续收到信心鼓励篇文章的点赞提醒，以及被关注提醒，还挺有成就感的呢，看来是真的有很多朋友需要测试方向的面经，那篇文章也没有给大家画饼，哈哈哈哈哈~~~~      那我就后续乖乖把剩下的几篇都更完，我睡觉觉啦，你们也要早点睡吖~~~[揉一揉]