脚本宝典收集整理的这篇文章主要介绍了测试开发面试——计算机网络篇，脚本宝典觉得挺不错的，现在分享给大家，也给大家做个参考。

七层：

应用层、表示层、会话层、传输层、网络层、数据链路层、物理层

 

五层：

应用层、传输层、网络层、数据链路层、物理层

 

路由器 在 网络层

交换机 在 数据链路层

 

三次握手：

1、第一次握手：客户端给服务器发送一个 SYN 报文。

2、第二次握手：服务器收到 SYN 报文之后，会应答一个 SYN+ACK 报文。

3、第三次握手：客户端收到 SYN+ACK 报文之后，会回应一个 ACK 报文。

4、服务器收到 ACK 报文之后，三次握手建立完成。

作用是为了确认双方的接收与发送能力是否正常。

这里我顺便解释一下为啥只有三次握手才能确认双方的接受与发送能力是否正常，而两次却不可以：

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。

第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

 

四次挥手：

刚开始双方都处于 establised 状态，假如是客户端先发起关闭请求，则：

1、第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于FIN_WaiT1状态。

2、第二次握手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT2状态。

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

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

5、服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

特别需要注意的就是TIME_WAIT这个状态了，这个是面试的高频考点，就是要理解，为什么客户端发送 ACK 之后不直接关闭，而是要等一阵子才关闭。这其中的原因就是，要确保服务器是否已经收到了我们的 ACK 报文，如果没有收到的话，服务器会重新发 FIN 报文给客户端，客户端再次收到 FIN 报文之后，就知道之前的 ACK 报文丢失了，然后再次发送 ACK 报文。

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

 

这里我给出每个状态所包含的含义，有兴趣的可以看看。

LISTEN – 侦听来自远方TCP端口的连接请求；

SYN-sENT -在发送连接请求后等待匹配的连接请求；

SYN-RECeiVED – 在收到和发送一个连接请求后等待对连接请求的确认；

ESTABLISHED- 代表一个打开的连接，数据可以传送给用户；

FIN-WAIT-1 – 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；

FIN-WAIT-2 – 从远程TCP等待连接中断请求；

CLOSE-WAIT – 等待从本地用户发来的连接中断请求；

CLOSING -等待远程TCP对连接中断的确认；

LAST-ACK – 等待原来发向远程TCP的连接中断请求的确认；

TIME-WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认；

CLOSED – 没有任何连接状态；

 

(1)TCP是可靠传输,UDP是不可靠传输;

(2)TCP面向连接,UDP无连接;

(3)TCP传输数据有序,UDP不保证数据的有序性;

(4)TCP不保存数据边界,UDP保留数据边界;

(5)TCP传输速度相对UDP较慢;

(6)TCP有流量控制和拥塞控制,UDP没有;

(７)TCP是重量级协议,UDP是轻量级协议;

(８)TCP首部较长20字节,UDP首部较短８字节;

 

常见的TCP协议和UDP协议：

HTTP、HTTPS、FTP、TELNET、SMTP(简单邮件传输协议)协议基于可靠的TCP协议。

tftp、DNS、DHCP、TFTP、SNMP(简单网络管理协议)、RIP基于不可靠的UDP协议

 

补充：QQ是udp为主，tcp为辅

微信的文字传输是哪种方式？视频语音通话呢？ 微信主TCP

 

HTTP 80 HTTPS 443 FTP 20、21 SMTP 25 ssh 22 telnet 23

DNS 53 SNMP 161 www代理服务 8080 RPC 110 tomcat 默认8080

FTP 控制端口一般为21，而数据端口不一定是20，这和 FTP的应用模式有关，如果是主动模式，应该为20，如果为被动模式，由服务器端和客户端协商而定

HTTP/1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接

在 HTTP 中响应体的 Connection 字段指定为 keep-alive

HTTP1.0 其实也可以强制开启长链接，例如接受Connection: keep-alive 这个字段，但是，这不是标准字段，不同实现的行为可能不一致，因此不是根本的解决办法。

 

HTTP/1.1 引入了持久连接。所谓的持久连接即TCP连接默认不关闭，可以被多个请求复用；客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。或者客户端在最后一个请求时，主动告诉服务端要关闭连接。

HTTP/1.1版还引入了管道机制（piPElining），即在同一个TCP连接里面，客户端可以同时发送多个请求。这样就进一步改进了HTTP协议的效率

 

HTTP/2.0 为了解决HTTP/1.1中仍然存在的效率问题，HTTP/2.0 采用了多路复用。即在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应。能这样做有一个前提，就是HTTP/2.0进行了二进制分帧，即 HTTP/2.0 会将所有传输的信息分割为更小的消息和帧（frame）,并对它们采用二进制格式的编码。

 

 

 

 

 

 

 

1xx：表示目前是协议的中间状态，还需要后续请求

2xx：表示请求成功

3xx：表示重定向状态，需要重新请求

4xx：表示请求报文错误

5xx：服务器端错误

常见的：

101 切换请求协议，从 HTTP 切换到 WebSocket

200 请求成功，有响应体

301 永久重定向：会缓存

302 临时重定向：不会缓存

304 协商缓存命中

403 服务器禁止请求访问

404 请求的资源未找到

400 请求语法错误

500 服务器端错误

502 Bad Gateway 作为网关或者代理服务器尝试执行请求时，从远程服务器接收到无效的响应。

503 服务器繁忙

 

 

TCP的面向连接是基于网络底层的数据传输。

HTTP的无连接是基于应用层面的沟通交互。

 

GET 用于获取资源，而 POST 用于传输实体主体。

 

 

DNS解析过程：

https://www.cnblogs.com/zhja/p/5591719.htML

 

 

 

Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在集群、数据库、文件中。

Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。

 

 

 

C/S架构的优缺点：

*优点：

1.客户端因为是独立设计，所以可以实现个性化

2.因为客户端是需要进行安装的，可以不需要重复安装和加载

3.因为客户端是独立开发的，所以有能力对客户端进行安全设计

4.如果遇到不同的操作系统，需要为不同的操作系统各开发一套客户端

*缺点：

1.因为客户端是不需要重复安装，所以用户可以不更新与升级，增加了维护成本。

2.因为需要开发客户端和服务器两套程序，所以开发成本会增加

 

B/S架构的优缺点：

*优点：

1.因为B/S架构具备通用性，所以开发成本较低。

2.因为不需要安装客户端，所以客户端不需要进行升级，只需要更新后台代码即可实现所有客户端的更新。

3.因为B/S架构多用WEB网页进行开发，所以增、删功能也非常容易，只需要修改网页即可完成

*缺点：

1.耗流量，每次都要加载全部的内容（不过有缓存可以降低流量损耗）

2.因为没有独立的客户端，所以无法实现个性化（通过账号体系可以实现）

3.因为没有独立设计客户端，所以客户端难以实现安全控制（HTTPS、控件）。

4.难以实现特殊的操作（删本地文件），所以所有的杀毒软件都是C/S架构的。

B/S架构更多的时候是使用了HTTP协议、而C/S架构更多的时候使用的WinSocket协议（TCP、UDP）

脚本宝典总结

以上是脚本宝典为你收集整理的测试开发面试——计算机网络篇全部内容，希望文章能够帮你解决测试开发面试——计算机网络篇所遇到的问题。

如果觉得脚本宝典网站内容还不错，欢迎将脚本宝典推荐好友。

本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。