剑指Java面试-计算机网络整理（不定期更新！）

一、计算机网络架构

1.OSI七层参考模型

2.TCP/IP四层架构（OSI的实现）

TCP/IP协议族是一个四层协议系统，自底而上分别是数据链路层、网络层、传输层和应用层。每一层完成不同的功能，且通过若干协议来实现，上层协议使用下层协议提供的服务。

二、TCP相关

1.TCP三次握手

    握手是为了建立连接，TCP三次握手的流程图如下：

1. 第一次握手: 建立连接时, 客户端发送SYN包(seq=j)到服务器,并进入SYN_SEND状态,等待服务器确认.
2. 第二次握手: 服务器收到SYN包,必须确认客户的SYN(ack=j+1), 同时自己也发送一个SYN包(seq=k), 即SYN+ACK包,此时服务器进入SYN_RECV状态;
3. 第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1), 此包发送完毕,客户端和服务器进入ESTABLISHED状态, 完成三次握手.

为什么需要三次握手才能建立起连接

    为了初始化Sequence Number的初始值,这个号要作为以后数据通信的序号,以保证应用层接收到的数据不会因为网络上的传输问题而乱序,以及TCP会用这个序号来拼接数据.(慕课网)
    也可以解释为为了防止 已失效的链接请求报文突然又传送到了服务端，因而产生错误。(书呆子Rico)

客户端发出的连接请求报文并未丢失，而是在某个网络节点长时间滞留了，以致延误到链接释放以后的某个时间才到达Server。这是，Server误以为这是Client发出的一个新的链接请求，于是就向客户端发送确认数据包，同意建立链接。若不采用“三次握手”，那么只要Server发出确认数据包，新的链接就建立了。由于client此时并未发出建立链接的请求，所以其不会理睬Server的确认，也不与Server通信；而这时Server一直在等待Client的请求，这样Server就白白浪费了一定的资源。若采用“三次握手”，在这种情况下，由于Server端没有收到来自客户端的确认，则就会知道Client并没有要求建立请求，就不会建立链接。

握手的隐患—SYN超时

    在TCP三次握手创建一个连接时，以下两种情况会发生超时：

1. client发送SYN后，进入SYN_SENT状态，等待server的SYN+ACK。
2. server收到连接创建的SYN，回应SYN+ACK后，进入SYN_RECD状态，等待client的ACK。

    当超时发生时，无论Server还是Client都会不断重试直至超时,Linux默认等待63秒才断开连接(重试5次,指数型增长).

针对SYN Flood的防护措施

    恶意发送SYN报文,耗尽服务器SYN连接队列.
防护措施:

• SYN队列满后,通过tcp_syncookies参数回发SYN Cookie,若为正常连接则Client会回发SYN Cookie,直接建立连接.

建立连接后,Client出现故障怎么办

保活机制

• 开启保活功能的一方将向对方发送保活探测报文,若果未收到响应,则经过一段配置好的保活时间间隔后继续发送,直到尝试次数达到保活探测数仍未收到响应则中断连接.

2.TCP四次挥手

挥手是为了终止连接,TCP四次挥手的流程图如下:

1. 第一次挥手: Client发送一个FIN,用来关闭Client到Server的数据传送,Client进入FIN_WAIT_1状态;
2. 第二次挥手: Server受到FIN后,发送一个ACK给Client,确认序号为受到序号+1(与SYN相同,一个FIN占用一个序号),Server进入CLOSE_WAIT状态;此时TCP链接处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收.
3. 第三次挥手:Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态.
4. 第四次挥手:Client受到FIN后,CLient进入TIME_WAIT状态,接着发送一个ACK给Server,确认序号为收到序号+1,Server进入CLOSED状态,完成四次挥手.

为什么会有TIME_WAIT状态

TCP连接必须经过时间2MSL后才真正释放掉.
原因:

1. 确保有足够的时间让对方收到ACK包,如果被动端没有收到ACK就会触发重发FIN包,一来一去正好是俩个2MSL
2. 避免新旧连接混淆

为什么需要四次挥手才能断开连接

因为全双工,发送方和接收方都需要FIN报文和ACK报文.

服务器出现大量CLOSE_WAIT状态的原因

对方关闭socket连接,我方忙于读或写,没有及时关闭连接

• 检查代码,特别是释放资源的代码
• 检查配置,特别是处理请求的线程配置

3. UDP和TCP的区别

UDP协议特点:

• 面向非连接
• 不维持连接状态,支持同时向多个客户端传输相同的消息
• 数据包报头只有8个字节,额外开销较小
• 吞吐量只受限于数据生成速率,传输速率以及机器性能
• 尽最大努力交付,不保证可靠交付,不需要维持复杂的链接状态表
• 面向报文,不对应用程序提交的报文信息进行拆分或者合并

TCP与UDP的区别

    TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)协议属于传输层协议，它们之间的区别包括：

1. TCP是面向连接的，UDP是无连接的；
2. TCP是可靠的，UDP是不可靠的；
3. TCP只支持点对点通信，UDP支持一对一、一对多、多对一、多对多的通信模式；
4. TCP是面向字节流的，UDP是面向报文的；
5. TCP有拥塞控制机制;UDP没有拥塞控制，适合媒体通信；
6. TCP首部开销(20个字节)比UDP的首部开销(8个字节)要大；

可简单概括为以下几点:

1. 面向连接VS无连接
2. 可靠性
3. 有序性
4. 速度
5. 量级

4.TCP协议如何来保证传输的可靠性

    TCP提供一种面向连接的、可靠的****字节流服务。其中，面向连接意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个TCP连接。在一个TCP连接中，仅有两方进行彼此通信；而字节流服务意味着两个应用程序通过TCP链接交换8bit字节构成的字节流，TCP不在字节流中插入记录标识符。

对于可靠性，TCP通过以下方式进行保证：

• 数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据；
• 对失序数据包重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层；
• 丢弃重复数据：对于重复数据，能够丢弃重复数据；
• 应答机制：当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
• 超时重发：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
• 流量控制：TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。

5.TCP的拥塞处理

计算机网络中的带宽、交换结点中的缓存及处理机等都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏，这种情况就叫做拥塞。拥塞控制就是 防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。注意，拥塞控制和流量控制不同，前者是一个全局性的过程，而后者指点对点通信量的控制。拥塞控制的方法主要有以下四种：

慢启动

    不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小;

拥塞避免

    拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍，这样拥塞窗口按线性规律缓慢增长。

快重传

    快重传要求接收方在收到一个 失序的报文段 后就立即发出 重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

快恢复

    快重传配合使用的还有快恢复算法，当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半，但是接下去并不执行慢开始算法：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。

6.TCP滑动窗口

TCP最基本的传输可靠性来源于确认重传机制,TCP滑动窗口的可靠性确认重传基础上的,发送窗口就收到接收端对于本段滑动窗口内字节的ACK确认才会移动发送窗口的左边界,接收窗口只有在前面所有的段都确认的情况下才会移动左边界,当在前面还有字节未接收,但收到后面的字节的情况下,窗口是不会移动的并不对后续字节进行确认,以此确保对端会对这些数据进行重传.
滑动窗口的大小可以依据一定策略动态调整,应用会根据自身处理能力的变化,通过本端TCP接收窗口大小的控制,来实现对端的发送窗口进行流量限制

以上描述大家根据自己的理解说出来就没问题了

RTT和RTO

• RTT: 发送一个数据包到受到对应的ACK,所花费的时间
• RTO: 重传时间间隔

详细介绍：https://blog.csdn.net/yao5hed/article/details/81046945

三、HTTP与HTTPS

1. HTTP(超文本传输协议)

HTTP主要特点

1. 支持客户/服务器模式(请求-响应)
2. 简单快速
3. 灵活
4. 无连接
5. 无状态

HTTP请求/响应的步骤

1. 客户端连接到WEB服务器
2. 发送HTTP请求
3. 服务器接受请求并返回HTTP响应
4. 释放TCP连接
5. 客户端浏览器解析HTML内容

2.HTTP状态码

• 1xx: 指示信息–表示请求已接受,继续处理
• 2xx:成功–表示请求已被成功接收,理解,接受
• 3xx:重定向–要完成请求必须进行更进一步的操作
• 4xx: 客户端错误–请求有语法错误或请求无法实现
• 5xx: 服务器端错误–服务器未能实现合法的请求

HTTP常见状态码：

• 200 OK:正常返回信息
• 301 : 永久性转移
• 302 ：暂时性转移
• 304 ： 已缓存
• 400 BadRequest:客户端请求有语法错误,不能被服务器所理解
• 401 Unauthorized:请求未经授权,这个状态代码必须和WWW-Authenticate报头域一起使用
• 403 Forbidden: 服务器收到请求,但是拒绝提供服务
• 404 Not Found:请求的资源不存在,eg,输入了错误的URL
• 500 Internal Server Error:服务器发生不可预期的错误
• 503 Server Unavailable:服务器当前不能处理客户端的请求,一段时间后可能恢复正常

3.GET请求和POST请求的区别

从三个层面来解答:

• Http报文层面: GET将请求信息放在URL,POST放在报文体中
• 数据库层面: GET符合幂等性和安全性,POST不符合
• 其他层面: GET可以被缓存,被存储,而POST不行

4.HTTPS（身披SSL外壳的HTTP）

HTTPS是一种通过计算机网络进行安全通信的传输协议，经由HTTP进行通信，利用SSL/TLS建立全信道，加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。

PS:TLS是传输层加密协议，前身是SSL协议，由网景公司1995年发布，有时候两者不区分。

SSL（Security Sockets Layer，安全套接字）

• 为网络通信提供安全及数据完整性的一种安全协议
• 是操作系统对外的API，SSL3.0之后更名为TLS
• 采用身份验证和数据加密保证网络通信的安全和数据的完整性

加密的方式有哪些

• 对称加密：加密和解密都使用同一个密钥
• 非对称加密：加密使用的密钥和解密使用的密钥是不相同的
• 哈希算法：将任意长度的信息转换为固定长度的值，算法不可逆
• 数字签名：证明某个消息或者文件是某人发出/认同的

HTTPS数据传输流程

1. 浏览器将支持的加密算法信息发送给服务器
2. 服务器选择一套浏览器支持的加密算法，以证书的形式回发给浏览器
3. 浏览器验证证书的合法性，并结合证书公钥加密信息发送给服务器
4. 服务器使用私钥解密信息，验证哈希，加密响应信息回发浏览器
5. 浏览器解密响应信息，并对消息进行验真，之后进行加密交互数据

HTTP与HTTPS的区别

1. HTTPS需要到CA（认证机构）申请证书，HTTP不需要
2. HTTPS密文传输（消耗更多的CPU和内存资源），HTTP明文传输
3. 连接方式不同，HTTPS默认使用443端口，HTTP使用80端口
4. HTTPS=HTTP + 加密+认证+完整性保护，较HTTP安全

HTTPS真的安全么

浏览器默认填充http://，请求需要进行跳转（301、302），有被劫持的风险
可以使用HSTS（HTTP Strict Transport Security）优化

5.Cookie和Session区别

Cookie简介：

• 是由服务器发给客户端的特殊信息，以文本的形式存放在客户端
• 客户端在此请求的时候，会把Cookie回发
• 服务器接收到后，会解析Cookie生成与客户端相对应的内容

Session简介：

• 服务器端的机制，在服务器上保存信息
• 解析客户端请求并操作session id，按需保存状态信息

Session的实现方式：

1. 使用Cookie来实现： 服务器使用JSESSIONID写入Cookie中，客户端发送新的请求时将携带带JESSIONID的Cookie进行访问
2. 使用URL回写来实现：浏览器在访问服务器的所有请求链接中都携带JSEEIONID的请求参数

Cookie和Session的区别

• Cookie数据存放在客户的浏览器上，Session数据放在服务器上
• Session相对于Cookie更安全
• 若考虑减轻服务器负担，应当使用Cookie

6.在浏览器地址栏键入URL,按下回车之后经历的流程

详细一点的流程：

1. 浏览器查询 DNS，获取域名对应的IP地址:具体过程包括浏览器搜索自身的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询等。对于向本地DNS服务器进行查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析(此解析具有权威性)；如果要查询的域名不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析（此解析不具有权威性）。如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者迭代查询；
2. 浏览器获得域名对应的IP地址以后，浏览器向服务器请求建立链接，发起三次握手；
3. TCP/IP链接建立起来后，浏览器向服务器发送HTTP请求；
4. 服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；
5. 浏览器解析并渲染视图，若遇到对js文件、css文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；
6. 浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。

可简单的概括为如下几个步骤：

1. DNS解析
2. TCP连接
3. 发送HTTP请求
4. 服务器处理请求并返回HTTP报文
5. 浏览器解析渲染页面
6. 连接结束

四、Socket相关

Socket是对TCP/IP协议的抽象，是操作系统对外开放的接口

学习&参考

1. https://blog.csdn.net/justloveyou_/article/details/78303617
2. https://coding.imooc.com/class/303.html