1.OSI七层模型、TCP/IP四层模型、五层协议体系结构
1.1 - OSI七层模型从上到下依次为:
- 应用层:为应用程序提供网络服务;
- 表示层:数据格式转换、数据压缩和数据加密;
- 会话层:建立、断开和维护通信链接;
- 传输层:为上层协议提供端到端的可靠传输;
- 传输层(Transport layer)通过分段、流量控制和差错控制来保证通信的可靠性。
- 网络层:寻址和路由;
- 寻址寻的是每一个主机对应的逻辑地址:IP
- 路由 将数据包从源端发送到目的端可能有多种路径，网络层根据路由算法选择一条最佳路径进行数据传输。
- 数据链路层:定义通过通信媒介互连的设备之间传输的规范;
- 物理层:利用物理传输介质为数据链路层提供物理连接。
1.2 - TCP/IP四层模型
- TCP/IP是一个四层的体系结构，他包括（从下到上顺序）：网络接口层、网际层（用网际层这个名字是强调这一层是为了解决不同的网络的互联问题）、运输层、应用层。
- 不过从实质上讲，TCP/IP只有最上面的三层，因为最下面的网络接口层并没有具体内容
- TCP/IP协议不是仅 指TCP、IP这两个协议，而是包含了利用IP进行通信时所必须用到的协议群的统称，比如TCP、 UDP、FTP和HTTP等协议，这些协议组成了TCP/IP协议族。
1.3 - 五层协议体系结构：
- 五层体系的协议结构是综合了OSI和TCP/IP的优点的一种协议，包括（从下到上）：物理层、数据链路层、网络层、运输层、应用层。（最底下两层可以称为网络接口层）
- 注：五层协议的体系结构只是为介绍网络原理而设计的，实际应用还是TCP/IP四层体系结构。
1.4 - OSI模型为什么设计成分层的
- 解耦。
将OSI模型设计为7层，各层之间的设计开发互不影响，即使某一层的设计发生了重大变 化，主要保证上一层的输入和下一层的输出跟之前兼容就ok，这样设计出来的系统扩展性和灵 活性比较强; - 定界。通过分层，能够明确各个层要实现的功能，更易于单独实现每个分层的协议，界定各个 分层的具体责任和义务
2.什么是面向有连接型和面向无连接型
2.1 - 面向有连接型传输
包括会话建立、传输数据和会话断开，此外还包括保证传输可靠性的各种措施，比如超时重传、流量控制等，常⻅的面向有连接传输有TCP;
2.2 - 面向无连接型传输
仅提供基本的传输数据的功能，即使接收端不存在，发送端也能发送数据包，常⻅的面向无连接传输有UDP、IP。
3.UDP和TCP的区别是什么
- TCP是面向有连接型，UDP是面向无连接型;
- TCP是一对一传输，UDP支持一对一、一对多、多对一和多对多的交互通信;
- TCP是面向字节流的，即把应用层传来的报文看成字节流，将字节流拆分成大小不等的数据块，并添加TCP首部;UDP是面向报文的，对应用层传下来的报文不拆分也不合并，仅添加 UDP首部;
- TCP支持传输可靠性的多种措施，包括保证包的传输顺序、重发机制、流量控制和拥塞控制; UDP仅提供最基本的数据传输能力。
4.TCP和UDP对应的应用层协议有哪些
4.1 - TCP对应的典型的应用层协议:
- FTP:文件传输协议;
- SSH:远程登录协议;
- HTTP:web服务器传输超文本到本地浏览器的超文本传输协议。
4.2 - UDP对应的典型的应用层协议:
- DNS:域名解析协议;
- TFTP:简单文件传输协议;
- SNMP:简单网络管理协议
5.TCP的三次握手
TCP的三次握手就是在发送数据前通过“三次握手”的方式建立起这个通信连接，建立这个连接的目的 是让源端和目的端确认一下双方的发送报文能力和接收报文能力是正常的
5.1 - TCP报文首部
- 序号seq
对字节流的编号。例如第一个字节的序号为 301，如果携带的数据⻓度为 100 字节，那么下一个 报文段的序号应为 401。注意第一份报文段的序号是随机生成的，后面的报文段序号是根据上一 个报文段序号及报文⻓度生成的。 - 确认号ack
期望收到的下一个报文段的序号。例如 B 正确收到 A 发送来的一个报文段，序号为 501，携带的 数据⻓度为 200 字节，因此 B 期望下一个报文段的序号为 701，B 发送给 A 的确认报文段中确 认号就为 701。 - SYN
控制位的一种，用于建立连接，该位设为 1，表示希望建立连接，并对第一份报文的序号进行随
机初始化。 - ACK
控制位的一种，确认应答的字段有效，TCP规定除了最初建立连接时的 SYN 包以外该位必须设 为 1。 - FIN 控制位的一种，当FIN=1，表明此报文的发送方的数据已经发送完毕，要求关闭连接。
5.2 - 三次握手具体过程
图来源于知乎
- 第一次握手
Client端将SYN置为1，表示希望与Server端建立连接;序号seq初始化为J，并将该数据包发送给Server端，Client进入SYN_SENT状态，等待Server确认。 - 第二次握手
Server端检查报文发现SYN为1，知道了Client端想建立连接;Server端将SYN置为1，表示Server 端也希望与Clinet端建立连接;Server端将ACK置为1，表示收到了Client端建立连接的请求; Server端将seq初始化为K;Server端将ack置为J+1，这里ack=seq + 1，第二次握手 包括服务端确认客户端发来的报文和服务端向客户端发送报文两个过程。 - 第三次握手
Client收到报文后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1， ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连 接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可 以开始传输数据了。第三次握手包括客户端确认服务端发来的报文，客户端向服务端发送报文和 服务端确认客户端发来的报文三个过程。
6. TCP四次挥手
6.1 - 四次挥手的具体过程
图来源于知乎
- 第一次挥手
假设客户端主动发起断开请求，客户端向服务端发送报文，报文首部包括FIN=1，这个控制位代 表客户端想要断开连接;序列号seq=u，这时客户端进入FIN-WAIT-1(终止等待1)状态，停止发送数据，并等待服务端的确认。 - 第二次挥手
服务端收到客户端的报文后发出确认报文，控制位ACK=1;确认号ack=u+1;序列号seq=v;然 后服务端就进入CLOSE-WAIT(关闭等待)状态。TCP服务端会告知上层的应用进程来自客户端 的连接即将关闭，让应用程序做好相应的准备。此时客户端已经没有数据向服务端发送了，但服 务端向客户端发送数据，客户端依然能接收。 - 第三次挥手
客户端收到服务器确认报文后，进入FIN-WAIT-2状态。此时服务器再次发送报文，报文首部控制 位FIN=1，表示服务端向客户端发送断开连接请求;确认标志ACK=1;确认序号ack=u+1;序号 seq=w，然后服务器进入LAST-ACK(最后确认态)，等待客户端确认。 - 第四次挥手
客户端收到了服务端的断开连接的报文后，必须发出确认报文，标志位ACK=1;确认号ack=w+1; 序号seq=u+1;之后客户端就进入了TIME-WAIT(时间等待)状态。注意此时客户端的TCP连接 还没有释放，必须经过2*MSL(最⻓报文段寿命)的时间后，客户端才进入CLOSED状态关闭连 接。而服务端只要收到了客户端发送的确认报文后就会进入CLOSED状态关闭服务端连接。当客 户端和服务端都进入了CLOSED状态后，客户端和服务端之间的连接才完全断开。
6.2 - 为什么会有TIME_WAIT状态?
- 客户端发送给服务端回执后，有可能这个回执报文在传输途中丢失等原因，服务端并没有收 到，此时服务端会再次向客户端发送FIN=1的断开请求报文，如果客户端没有等待2*MSL时间 而直接进入了CLOSED状态，客户端就会收不到服务端再次发送的断开连接的请求报文，导致 服务端无法进入CLOSED状态;
- 等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的 连接不会出现旧的连接请求报文。
6.3 - 为什么是四次挥手而不是三次或者五次?
- 第二次挥手和第三次挥手都是服务端向客户端发送报文，第二次挥手是服务端收到了客户端的断开请求，通知客户端收到了，此时客户端没有数据向服务端发送了，但不代表服务端也没有数据向客户端发送，因为服务端要把剩余还没有发送的报文发送完毕再断开连接;第三次挥手是服务端数据全部发送完毕，向客户端发送断开请求报文(FIN=1)。
- 如果是三次挥手，即把服务端向客户端发送报文的第二次挥手和第三次挥手合为一次，会造成服务端发送了回执后立刻又发送断开请求，造成服务端有数据没有全部发送至客户端，因此必须将第二次挥手和第三次挥手分开;五次挥手则完全没必要，多此一举。
7.ARQ协议
ARQ协议，即自动重传请求(Automatic Repeat-reQuest)，意思是如果发送方在发送后一段时 间之内没有收到确认回执，它通常会重新发送。ARQ协议包括停止等待ARQ协议和连续ARQ协 议。
- 停止等待ARQ协议
停止等待ARQ协议是指，在停止等待中如果接收端没有收到发送端发来的分组，接收端就不会给 发送端发送确认回执，此时发送端会重新发送之前的报文分组。发送端会维护一个超时计时器， 超时时间会设置的比数据在传输往返过程的时间要⻓一些。 - 连续ARQ协议
连续ARQ协议是指，发送端维护一个“窗口”，“窗口”内可以有多个分组，窗口的大小就是窗口中 分组的个数，凡是位于“窗口”内的分组可以连续发送出去而不必等待接收端返回的确认回执，对按序到达的最后一个分组，接收端会向发送端发送确认回执，如果有分组没有正确到达，会返回最后一个正确达到的分组序号，该序号后面的分组会重新发送给接收端。
在连续ARQ协议中，发送端会维护一块发送端的数据缓存，“窗口”里的分组都会在这个缓存中， 当需要重新发送“窗口”中的分组报文时，便会从缓存里读取分组并发送。
连续 ARQ 协议可提高信道利用率。
8.TCP的流量控制
- 流量控制是为了控制发送端发送数据的速率，保证接收端能将本应接收的所有报文分组接收成 功，否则会触发自动重传机制造成网络流量的浪费。
- 流量控制的具体操作是:接收端会通知发送端自己能接收的数据大小，于是发送端会发送不超过 这个数据量的数据，这个大小被称为“窗口”的大小，在TCP首部中专⻔有一个字段表示“窗口”的 大小，该值越大代表网络的吞吐量越高。
9.TCP的拥塞控制
- 计算机网络都处在一个共享的环境，在通信开始时如果立即把大量数据注入到网络，可能会引起 网络阻塞，甚至带来网络瘫痪。TCP为了防止该问题的出现，采用了拥塞控制的策略，常⻅的拥 塞控制策略有慢启动、拥塞避免、快重传与快恢复
9.1 - 慢启动
- 在通信开始时，定义一个“拥塞窗口”，窗口大小为1，意思是开始时只发送一个分组，之后每收到一个确认回执(ACK)，拥塞窗口的大小就加1(即逐渐增大窗口大小)，发送端在发送数据时，将拥塞窗口的大小与接收端流量控制窗口的大小作比较，取二者中较小的值，然后实际发送 的数据量比这个最小值还要小。
10.TCP"粘包"问题
TCP是面向字节流的，不会存在粘包问题，所谓的'粘包'一般是是由于应用层造成的
10.1 - 什么是“粘包”
- TCP 是基于字节流的，虽然应用层和 TCP 传输层之间的数据交互是大小不等的数据块，但是
TCP 把这些数据块仅仅看成一连串无结构的字节流，没有边界; - 从 TCP 的帧结构也可以看出，在 TCP 的首部没有表示数据⻓度的字段
- 如果客户端连续不断的向服务端发送数据包时，服务端接收的数据会出现两个数据包粘在一起的情况
10.2 - “粘包”是如何产生的
- 发送方发生粘包
要发送的数据小于 TCP 发送缓冲区的大小，TCP 将多次写入缓冲区的数据一次发送出 去，将会发生粘包。 - 接收方发生粘包
接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。
10.3 - 如何避免“粘包”
- 在每个包的末尾加上特殊字符，用以区分连续的两个包;
- 在报文首部添加包的⻓度。
11.HTTP协议
11.1 - http与https的区别
- http协议是应用层的协议，中文名称是超文本传输协议，是客户端和服务端相互通信时将信息以 http报文的形式传输。
- https可以简单的理解为:https = http + 加密 + 认证 + 完整性保护。
- http协议的缺点:
- 通信使用明文，内容可能被窃听。
- 通信双方的身份无法得到认证，身份可能遭遇伪装。
- 无法验证报文的完整性。
- https的改进措施:
- 加密。https协议通过SSL或者TLS协议将报文内容进行加密，client端进行加密，server端进行解密。
- 认证。通过值得信赖的第三方机构颁布证书，即可确认通信双方的身份。客户端持有证书即可完成客户端身份的确认，客户端通信前会查看服务端的证书。
- 完整性保护。可以通过MD5等散列码进行通信内容的校验。
11.2 - 为什么说http协议是无状态协议?怎么解决Http协议无状态协议?
- http协议是一种无状态协议，协议自身不对请求和响应之间的通信状态进行保存，即对发送过来 的请求和响应都不做持久化处理，把http协议设计的如此简单是为了更快地处理大量事务。
- 为了解决http协议不能保存通信状态的问题，引入了Cookie状态管理。Cookie技术通过在请求和 响应报文中写入Cookie信息来控制客户端的状态。Cookie会根据从服务端发送的响应报文的一个叫Set-Cookie的首部字段，通知客户端保存Cookie。当下次客户端再往该服务端发送请求时，客 户端会自动在请求报文中加入Cookie值发送出去，服务端发现客户端发来的Cookie后，会检查是哪一个客户端发来的连接请求，对比服务器上的记录，最后得到之前的状态信息。
11.3 - URI和URL的区别?
- URI: Uniform Resource Identifier，统一资源标识符，用来唯一标识互联网中的一份资源。
- URL: Uniform Resource Locator，统一资源定位符，我们访问网站的网址就是URL。
- URL是URI的子集。
- URI相当于抽象类，URL就是这个抽象类的具体实现类。
11.4 - 常⻅的http动词
- GET: 从服务器获取资源
- POST: 在服务器新建资源
- PUT: 在服务器更新资源
- DELETE: 在服务器删除资源
- HEAD: 获取资源的元数据
- OPTIONAL: 查询对指定的资源支持的方法
11.5 - put和post的区别
- put是幂等的，post不是。
- 幂等是数学的一个用语，对于单个输入或者无输入的运算方法，如果每次都是同样的结果，则称其是幂等的。也就是说，如果一个网络重复执行多次，产生的效果是一样的，那就是幂等 (idempotent)。
- post在发请求的时候，服务器会每次都创建一个文件，而put发请求的时候，是更新文件而不是创建文件，因此put是幂等的。
11.6 - 常⻅的http返回码
- 2** 处理请求成功。
200:请求被正常处理
204:请求被受理但没有资源可以返回
206:客户端只是请求资源的一部分，服务器只对请求的部分资源执行GET方法，相应报文中通过Content-Range指定范围的资源。
- 3** 重定向。
301:永久性重定向
302:临时重定向
303:与302状态码有相似功能，只是它希望客户端在请求一个URI的时候，能通过GET方法重
定向到另一个URI上
304:发送附带条件的请求时，条件不满足时返回，与重定向无关
307:临时重定向，与302类似，只是强制要求使用POST方法
- 4** 处理请求失败，问题出在client端，可能是发起请求的一方没有权限、API格式不正确等原因。
400:请求报文语法有误，服务器无法识别
401:请求需要认证
403:请求的对应资源禁止被访问
404:服务器无法找到对应资源
5** 处理请求失败，问题出在server端，一般就是后台程序哪里写的有bug，要检查我们的服务端代 码。
500:服务器内部错误
503:服务器正忙
11.7 - HTTP报文
-
http报文说白了就是client和server通信时依据http协议，将传输的信息以文本的形式呈现，这个 文本就是http报文。http报文分为请求报文和消息报文，这两类报文有着相同的结构组成
图片来源知乎 - 报文四部分：
- 请求行/响应行
请求行由http动词，请求uri和http版本组成，主要是反应这次请求要对什么资源做什么操作
响应行由http返回码，原因短语和http版本组成，呈现的服务端对这次请求的处理结果， - 首部字段
首部字段又叫头域(header)，相当于http报文的元数据，记录了这次http报文的具体描述信息，比如时间、服务端域名等。 - 空行
用来区分首部字段和报文主体。 - 报文主体
报文主体并不是每个报文都有的，要看具体的报文是要做什么，报文主体返回的格 式一般是xml或者json格式。
12.TCP长连接和短链接的区别
- 短连接:
Client 向 Server 发送消息，Server 回应 Client，然后一次读写就完成了，这时候双方任 何一个都可以发起 close 操作，不过一般都是 Client 先发起 close 操作。短连接一般只会在 Client/Server 间传递一次读写操作。 - ⻓连接:
Client 与 Server 完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作 会继续使用这个连接。
13. 提高网络利用率
13.1 - Nagle 算法
- 发送端即使还有应该发送的数据，但如果这部分数据很少的话，则进行延迟发送的一种处理机 制。具体来说，就是仅在下列任意一种条件下才能发送数据。如果两个条件都不满足，那么暂时 等待一段时间以后再进行数据发送。
- 已发送的数据都已经收到确认应答。
- 可以发送最大段⻓度的数据时。
13.2 - 延迟确认应答
- 接收方收到数据之后可以并不立即返回确认应答，而是延迟一段时间的机制。
- 在没有收到 2*最大段⻓度的数据为止不做确认应答。
- 其他情况下，最大延迟 0.5秒 发送确认应答。
- TCP 文件传输中，大多数是每两个数据段返回一次确认应答。
13.3 - 捎带应答
- 在一个 TCP 包中既发送数据又发送确认应答的一种机制，由此，网络利用率会提高，计算机的负荷也会减轻，但是这种应答必须等到应用处理完数据并将作为回执的数据返回为止。
14. TCP四层模型常用协议
image.png