基础面试题 — 计算机网络

有感而发

做为计算机相关专业的必修课之一，计算机网络在编程中的地位从未被超越。整个社会都在高度依赖网络所提供的各类服务，咱们一边享受网络所提供的便利，一边也在经过网络成为被贩卖的对象，网络安全的重要性，日益凸显。此外，若是太依赖于网络，每天生活在网络中，在必定程度上也会削弱咱们在实际生活中的各项技能，所以，审时度势，合理利用网络，方能让咱们活得更出彩。若是咱们告别各类电子设备，回归到煤油灯的生活，想一想天天都有大把的时间，能够作……也能够作……（反正不会熬夜）。

计算机网络体系结构

计算机网络的体系结构也就是咱们熟知的七层网络模型或五层网络模型，接下来从下往上大体介绍下各个层级及其做用：

• 物理层：其任务是规范物理传输媒介相关接口的特性（可理解为把光电信号转换成0或1比特数据，根据0或1比特数据转换成对应的光电信号）；
• 数据链路层：在相邻节点之间透明传送被封装成帧的IP数据报（封装成帧，透明传输）；
• 网络层（IP层）：经过选择合适的路由，为网络系统中的主机提供通讯服务（路由选择，地址解析等）；
• 传输层：经过传输层的协议，为不一样主机间的应用进程提供通讯服务（经过端口区分进程）；
• 会话层：负责处理不一样主机进程间会话的创建、控制和关闭（会话管理，数据流同步）；
• 表示层：负责根据数据格式、编码、压缩和解压缩、加密和解密，转换计算机和网络通讯间的数据格式；
• 应用层：为用户应用程序提供通讯服务，保证通讯双方的可用性和数据的完整性；

一些关键词

• ping：ICMP网际控制报文协议，通常使用ICMP协议的回送请求和回送应答测试两个主机之间的连通性；
• MTU：Maximum Transfer Unit最大传送单元，即IP数据报，链路层所容许的最大传输单元；
• MSS：Maximum Segment Size最大报文段长度，即传送到IP层不须要分片的长度；

差错检验

• 传输层：对数据段和头部总体校验（IP头部长度：TCP20字节，UDP8字节）；
• 网络层：只校验首部（IP层首部20字节）；
• 链路层：比特差错校验（校验0和1）；

TCP和UDP的区别？

协议	面向链接？	可靠交付？	点对点？	拥塞避免？	流量控制？	面向字节or报文？
UDP	无链接	尽最大努力但不保证可靠	一对1、多对多、多对1、多对多	不支持	不支持	面向报文
TCP	面向链接	保证可靠	只支持一对一	支持	支持	面向字节流（会对字节进行编号）

TCP 为什么要三次握手和四次挥手？

TCP是面向链接的，因此在数据传输以前要先创建链接，3次握手是为了创建链接，数据传输完毕后必需要释放链接，4次挥手就是为了释放链接。

• 三次握手（简化版）
  1. 服务端建立传输控制块TCB，准备接收客户端的链接请求并进入LISTEN（收听）状态，客户端建立TCB后向服务端发送链接请求报文；
  2. 服务端收到后随即发出确认报文（此时还没创建链接）；
  3. 客户端收到服务器端的确认后再发出一次确认报文，服务端收到后创建链接，握手结束。

PS：客户端最后发送的那次确认主要是为了防止已失效的链接请求报文忽然又传送到服务端，于是产生错误和致使服务端资源浪费。

• 四次挥手（简化版）
  1. 客户端应用进程先向其TCP发出链接释放报文并中止数据的发送，进入终止等待状态
  2. 服务端收到后随即发出去确认并进入关闭等待状态，客户端收到确认后进入终止等待状态2，若服务端仍有数据须要发送给客户端，客户端仍然须要接收。
  3. 服务端确认没有须要向客户端发送的数据后，服务端应用进程通知TCP释放链接，并进入最后确认状态，等待客户端的确认
  4. 客户端收到服务端的链接释放的报文后，向服务端发出确认，服务端收到确认后关闭链接，客户端在等待最长报文寿命结束后也关闭链接(若服务端超时没有收到确认，则须要重发释放链接的请求，此时客户端会继续发出确认并从新开启一个等待计时器；防止已失效的链接请求报文出如今本链接中）

TCP 如何保证可靠的？

TCP协议主要是经过确认和重传机制来保证可靠交付，TCP会对报文数据进行编号，每一个报文段都有起始编号和尾部编号，一个报文段能够理解为一个发送窗口的大小，也就是发送方来在未收到对方确认的状况下能够连续发送的报文大小。

1. 对于发送方来讲发送报文段数据时，同时开启超时计时器，在未收到确认以前都会暂时保留一份副本，发送方通过一段时间后（由超时计时器控制）就重传这部分数据（多是发送方发送的报文超时，也多是接收方发送的确认超时），并从新设置超时计时器，直到收到确认为止。
2. 发送方接收到确认（已收到的报文号段和期待下次接收的报文号段）后，移除保留的对应的报文段副本（从发送缓存中移除），并移动发送窗口，发送新的数据。
3. 接收方把接收到的报文段放到接收缓存中，包括按序到达的、但还没有被接收应用程序读取的数据和未按序到达的数据。接收方等到字节流中所缺乏的字节收到后，再按序交付给上层的应用进程。
4. 接收方若是收到的分组被检测出有差错或重复的数据就会丢弃，接收方可能会有缺失的报文段，对于接收方来讲没有收到就不会发送确认，此时发送方会重传未被确认的报文段。

TCP 流量控制

流量控制就是让发送发的发送速率不要太快，要让接收方来得及接收。假设A向B发送数据，在链接创建时，B告诉A个人接收窗口rwnd="400"（rwnd表示receiver window，字节单位），假设一个报文段长度是100字节，A发送了序号1-100的报文段，还能发送300字节，A发送序号101-200报文段，还能发送200字节，此时B发送了序号1-100报文段和rwnd=300字节的确认报文，此时A可发送的大小就是300字节，若是A已发送了400字节，就不容许A再发送数据了，容许A超时重发旧的数据，但不容许A发送新数据，总的来讲就是接收方控制发送方发送数据的速率，以便接收方来得及接收。

TCP 拥塞控制

TCP主要经过慢开始和拥塞避免进行拥塞控制。在不清楚网络负荷的状况下，若把大量数据发送到网络，那么就可能引发网络拥塞，因此会先探测一下，即从小到大逐渐增大拥塞窗口（等同于发送窗口），当网络出现拥塞再把拥塞窗口减少一些，以减小注入到网络中的分组数。

1. TCP初始化时会把拥塞窗口设置为一个MSS大小，并初始化慢开始门限（调节发送窗口大小）的值，在每收到一个对新的报文段的确认后，把拥塞窗口增长至多一个MSS的数值（1变2，2变4，4变8），用这样的方法逐步增大发送方的拥塞窗口cwnd，使报文注入到网络的速率更加合理。
2. 随着传输轮次的增长，拥塞窗口的大小曾指数级增加，当拥塞窗口的大小等于慢开始门限的值时，此时会从慢开始切换到拥塞避免，能够理解为把拥塞窗口以前的指数级增加改成线性缓慢增加（通过一个往返时间拥塞窗口仅增长一个MSS大小）。
3. 随着拥塞窗口的逐渐增大，当检测到报文超时（在超时计时器内没有收到确认），就把慢开始门限的值更新为出现拥塞时拥塞窗口大小的一半，同时把拥塞窗口的大小从新置为一个MSS，并开始执行慢开始算法，如此往复。

HTTP的组成部分

HTTP由三部分组成：开始行、Header和Body体；

• 开始行：用于区分是请求行仍是响应行
  • 请求行：Method URL HTTP/Version，如：GET /Joelixy/IVAlgorithms HTTP/1.1；
  • 状态行：HTTP/Version StatusCode StatusMsg，如：HTTP/1.1 404 Not Found；
• Header

  • Request Header（通常有如图所示字段，也可自定义）

    

  • Response Header（具体请参考下图）

    

• Body
  • 通常的POST请求只有相关参数，上传文件的POST请求会包含被编码的文件数据。

上传文件的HTTP请求

• —$boundary：能够认为是Body的边界
• Content-Disposition：用于指定呈现方式，如：from-data：name="txt"
• Content-Type：
  • application/x-www-form-urlencoded：用来提交文本，不能上传文件，用$_POST[]接收
  • multipart/form-data：用来提交表单数据，用$_FILES接收
• Content-Transfer-encoding：默认的编码行不通时可指定编码方式
• 数据：被上传的编码后的数据

GET和POST的区别

1. GET从服务端获取数据，POST向服务端传送数据
2. GET参数添加到表单的ACTION属性所指的URL中；POST中将字段及其内容放置在HTML HEADER内一块儿传送到ACTION属性所指的URL地址，用户看不到这个过程。
3. 服务端用Request.QueryString获取变量的值，用Request.Form获取表单中的数据
4. GET传送数据量较小，2KB之内，POST不受限，主要取决于服务端的限制
5. 安全性不同，GET请求直接暴露给用户了，且还可能被服务器记录，有泄漏风险；POST的全部操做对用户都是不可见的

网络安全

密码体制

主要有两种，一种是对称秘钥密码体制，另外一种是公钥密码体制。

• 对称密钥密码体制：即加密与解密都是相同的密码体制，加解密速度快，可是若不对密钥分发的过程加以保护，密钥泄漏的风险仍是很高。
• 公钥密码体制：使用不一样的加密密钥和解密密钥，即公钥和私钥，公钥是公开的，私钥是保密的，公钥加密的数据只有私钥能解密，私钥加密的数据只有公钥能解密。

密钥分配

因为密码算法是公开的，因此网络的安全性就彻底基于密钥的安全之上，所以密钥的管理和分发就显得无比重要了。目前通用的作法是：

• 用公钥分发：经过公钥对临时会话产生的对称密钥进行加密，而后进行分发，私钥解密后，双方就按照约定的加密方式进行加解密，对称密钥对数据加解密，公私钥用于对报文鉴别。
• 双向验证：通讯的双方都有本身的公钥和私钥对，通讯时经过证书的解析获得对方的公钥，而后双发都有了本身的私钥和对方的公钥，这样就能够互相解密对方的加密数据，只是这种方式效率过低，不适合频繁的网络请求场景。

数字签名

签合同的时候，咱们都须要进行签名，就是为了保证其真实性，经过验证签名来代表这份合同的真实性。数字签名就是为了保证这个数据是某个发送者发送的，由于只有它才能够有这样的签名，因此数字签名必须保证三点功能：“报文鉴别、报文的完整性和不能否认”。

1. 报文鉴别：接收者可以核实发送者对报文的签名，也就是说，接收者能够鉴别该报文的确是发送者发送的，其余人没法伪造对报文的签名。
2. 报文的完整性：接收者确信所收到的数据和发送者发送的彻底同样，没有被篡改过，这就叫报文的完整性。
3. 不能否认：发送者过后不能抵赖对报文的签名。

HTTPS如何对报文鉴别来保证数据的完整性？

1. 以客户端和服务端为例，服务端在发送报文时，会经过报文摘要算法对报文进行计算获得报文摘要，而后服务端用本身的私钥对报文摘要进行签名，最后把签名后的报文摘要追加到报文后一块儿发送给客户端。
2. 客户端在收到服务端的报文后，把签过名的报文摘要和报文进行分离后，会作两件事，（1）客户端用服务端的公钥对签过名的报文摘要解密获得报文摘要，（2）对接收的报文进行报文摘要计算，也会获得一个报文摘要。客户端对比两个报文摘要，若相等则说明收到的报文就是服务端发送的，相等也说明数据没有被篡改过，不然说明数据被篡改或不是服务端发送的。
3. 同理，客户端发送报文时也同样，用本身的公钥对报文摘要签名，而后追加到报文后发送给服务端，服务端用私钥解密，并作一样的事情，来对报文进行鉴别。

HTTPS的握手流程

• 客户端：向服务端发送clientHello以及支持的SSL版本号和加密套件、随机字符串（后面协商对称秘钥的时候须要）
• 服务端：向客户端发送ServerHello以及支持的SSL版本号和选择的加密套件、随机字符串和服务器的证书（被CA机构的私钥签名过的证书，有RSA公钥、域名、版本、签名使用的加密算法等，若须要双向验证，则须要客户端也提供相应的证书，此处只考虑单向验证）
• 客户端：支持HTTPS的通常都有个可信的CA表（内置客户端或系统中），表中有CA的公钥（CA认证中心的公钥都是公开的）。客户端收到服务端的证书时就检查此证书的发行者是否在本身的可信CA表中。若不在则没法创建加密链接，若在就使用CA表中相应的公钥对证书校验并解密获得服务端的公钥。而后用公钥加密客户端产生的随机字符串并发送给服务端，服务端收到后用私钥解密获得随机字符串，此时双方都有三个字符串，会用约定的加密方式加密随机字符串生成对称密钥。
• 客户端：向服务器发送一个报文，说明之后客户端将使用此会话对称密钥进行加解密。而后客户端再向服务器发送一个单独的加密报文，代表客户端的握手过程已完成。
• 服务端：也向客户端发送一个报文，说明之后服务端将使用此会话密钥进行加解密，而后服务端再向客户端发送一个单独的加密报文，代表服务端的握手过程已完成。
• 此时SSL握手已经完成，下面就能够开始SSL的会话；

淘宝页面发送HTTP请求的过程

• DNS解析（查找过程：本地域名Server(DNS高速缓存)->根域名Server->COM顶级域名Server
  • 先查找浏览器的DNS缓存->系统的DNS缓存->DNS服务器(先查找本身的DNS缓存->根域名Server->COM顶级域名->域名注册商
  • 如：www.google.com域名，真实的域名是www.google.com.多一个点，浏览器向DNS请求时会自动添加该点，表示根域名服务器。
  • DNS缓存：浏览器缓存-系统缓存-路由器缓存-IPS服务器缓存-跟域名Server-顶级域名Server-主域名Server
• TCP创建链接
  • 拿到域名IP地址后，客户端以一个随机端口向服务器的Web程序80端口发起链接请求，链接请求通过下面4层网络模型层层封装到达服务端，进入到服务端的内核的TCP/IP协议栈，识别链接请求层层解开数据报，找到80端口到达Web程序，
• 发送HTTP请求（三部分）
  • GET：要求服务器将URL定位的资源放在响应报文的数据部分发送给客户端，URL和参数经过“？”分割
  • POST：将数据封装在HTTP请求数据中(HTML HEAD)
• 服务器处理HTTP请求并返回HTTP报文
  • 处理后就把数据返回给客户端HTML数据
• 客户端解析数据并渲染页面
  • 客户端解析HTML拿到数据，而后开始渲染页面
• 断开TCP链接
  • 服务端在一段时间后若没有收到客户端的请求，链接就会关闭；

总结

网络是那么的重要，几乎每一个项目都避不开它，并且还可能会出现不少奇奇怪怪的网络问题，因此有关网络的相关基础理论是编写和调试网络模块的必备知识，最好经过调试来了解请求是如何创建和相互通讯的。

---

PS：以上描述的相关知识点，由我的总结并进行了简化，不免会有不足和错误的地方，欢迎你们指正！