网络面试题

1.三次握手和四次挥手的过程？每次发送的包的内容，客户端和服务端的状态？

答：
三次握手过程是：
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED（连接）状态，完成三次握手。完成三次握手，客户端与服务器开始传送数据.

为什么要三次握手？
第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。所以三次握手就能确认双发收发功能都正常，缺一不可

四次挥手
第一次挥手：A数据传输完毕需要断开连接，A的应用进程向其TCP发出连接释放报文段（FIN = 1,序号seq = u）,并停止再发送数据，主动关闭TCP连接，进入FIN-WAIT-1状态，等待B的确认。
第二次挥手：B收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1,序号seq=v）,B进入CLOSE-WAIT关闭等待状态,此时的TCP处于半关闭状态，A到B的连接释放。而A收到B的确认后，进入FIN-WAIT-2状态，等待B发出的连接释放报文段。
第三次挥手：当B数据传输完毕后，B发出连接释放报文段（FIN = 1，ACK = 1，序号seq = w,确认号ack=u+1）,B进入LAST-ACK（最后确认）状态，等待A 的最后确认。
第四次挥手：A收到B的连接释放报文段后，对此发出确认报文段（ACK = 1，seq=u+1，ack=w+1）,A进入TIME-WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，A才进入CLOSE状态。

关闭连接时，被动关闭方可能还需要发送一些数据后，再发送FIN报文表示同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的，所以需要四次挥手。

2.ICMP协议的应用？ （ping命令和traceRoute等）

答：
ICMP（Internet Control Message Protocol）网络控制报文协议。它是TCP/IP协议簇的一个子协议，用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。
ICMP协议是一种面向无连接的协议，用于传输出错报告控制信息。它是一个非常重要的协议，它对于网络安全具有极其重要的意义。 [3] 它属于网络层协议，主要用于在主机与路由器之间传递控制信息，包括报告错误、交换受限控制和状态信息等。当遇到IP数据无法访问目标、IP路由器无法按当前的传输速率转发数据包等情况时，会自动发送ICMP消息。

以 ping 和 tracert 命令为例详细介绍 ICMP 协议的应用。
(1) ping 命令使用 ICMP 回送请求和应答报文 在网络可达性测试中使用的分组网间探测命令 ping 能产生 ICMP 回送请求和应答报文。目的主机收到 ICMP 回送请求报文后立刻回送应答报文,若源主机能收到 ICMP 回送应答报文,则说明到达该主机的网络正常。
(2)路由分析诊断程序 tracert 使用了 ICMP时间超过报文 tracert 命令主要用来显示数据包到达目的主机所经过的路径。通过执行一个 tracert 到对方主机的命令,返回数据包到达目的主机所经历的路径详细信息,并显示每个路径所消耗的时间。”

3.TCP如何保证可靠性？

（校验和，分片，超时重传，ARQ协议，滑动窗口等等）

答：

校验和：如果接收方比对校验和与发送方不一致，那么数据一定传输有误。但是如果接收方比对校验和与发送方一致，数据不一定传输成功。
序列号：序列号：TCP传输时将每个字节的数据都进行了编号，这就是序列号。
确认应答：TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。
超时重传：在进行TCP传输时，由于确认应答与序列号机制，也就是说发送方发送一部分数据后，都会等待接收方发送的ACK报文，并解析ACK报文，判断数据是否传输成功。如果发送方发送完数据后，迟迟没有等到接收方的ACK报文，这该怎么办呢？而没有收到ACK报文的原因可能是什么呢？
首先，发送方没有接收到响应的ACK报文原因可能有两点：

1. 数据在传输过程中由于网络原因等直接全体丢包，接收方根本没有接收到。
2. 接收方接收到了响应的数据，但是发送的ACK报文响应却由于网络原因丢包了。
3. TCP在解决这个问题的时候引入了一个新的机制，叫做超时重传机制。简单理解就是发送方在发送完数据后等待一个时间，时间到达没有接收到ACK报文，那么对刚才发送的数据进行重新发送。如果是刚才第一个原因，接收方收到二次重发的数据后，便进行ACK应答。如果是第二个原因，接收方发现接收的数据已存在（判断存在的根据就是序列号，所以上面说序列号还有去除重复数据的作用），那么直接丢弃，仍旧发送ACK应答。

连接管理：连接管理就是三次握手与四次挥手的过程，保证可靠的连接，是保证可靠性的前提。
流量控制：接收端在接收到数据后，对其进行处理。如果发送端的发送速度太快，导致接收端的结束缓冲区很快的填充满了。此时如果发送端仍旧发送数据，那么接下来发送的数据都会丢包，继而导致丢包的一系列连锁反应，超时重传呀什么的。而TCP根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制
拥塞控制：拥塞控制是TCP在传输时尽可能快的将数据传输，并且避免拥塞造成的一系列问题。是可靠性的保证，同时也是维护了传输的高效性。

4.如何实现UDP的可靠传输？

UDP不属于连接协议，具有资源消耗少，处理速度快的优点，所以通常音频，视频和普通数据在传送时，使用UDP较多，因为即使丢失少量的包，也不会对接受结果产生较大的影响。

传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。

最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理，可靠UDP的简单设计。

1. 添加seq/ack机制，确保数据发送到对端
2. 添加发送和接收缓冲区，主要是用户超时重传。
3. 添加超时重传机制。

详细说明：送端发送数据时，生成一个随机seq=x，然后每一片按照数据大小分配seq。数据到达接收端后接收端放入缓存，并发送一个ack=x的包，表示对方已经收到了数据。发送端收到了ack包后，删除缓冲区对应的数据。时间到后，定时任务检查是否需要重传数据。

目前有如下开源程序利用udp实现了可靠的数据传输。分别为RUDP、RTP、UDT。

5.https的请求过程？

1.客户端想服务器发起HTTPS的请求，连接到服务器的443端口；
2.服务器将非对称加密的公钥传递给客户端，以证书的形式回传到客户端
3.服务器接受到该公钥进行验证，就是验证2中证书，如果有问题，则HTTPS请求无法继续；如果没有问题，则上述公钥是合格的。（第一次HTTP请求）客户端这个时候随机生成一个私钥，成为client key,客户端私钥，用于对称加密数据的。使用前面的公钥对client key进行非对称加密；
4.进行二次HTTP请求，将加密之后的client key传递给服务器；
5.服务器使用私钥进行解密，得到client key,使用client key对数据进行对称加密
6.将对称加密的数据传递给客户端，客户端使用非对称解密，得到服务器发送的数据，完成第二次HTTP请求。

6.一次RPC调用的整个链路？

RPC英文全称remote procedure call 翻译成中文的意思就是远程过程调用。RPC的出现其实主要是为了解决分布式系统间的通信透明性的问题。

RPC采用C/S模式，客户端发送请求，服务端响应。基于底层的协议，比如TCP/IP模式。

1.当应用开始调用PRC的方式时，就会去容器中去取Bean对象，所以应该先注册Bean对象到容器中,通过Java的动态代理，将代理过程封装到代理对象中，代理对象实现接口，创建实例到容器中。相应的，在调用远程对象的对象方法时，就会调用动态代理中的方法，这就是代理层的作用。

2.代理对象在获取到请求方法、接口和参数时，就会用序列化层，将这些信息封装成一个请求报文，再让通信层向服务端传送报文的内容，然后就到了生产者这块。

3.相应的服务必须有个监听器，来监听来自其他服务的请求，一般都会用容器做消息的监听，就会调用对应的Bean对象的方法，去处理响应的请求。当然，RPC框架不会让容器中的每一个框架都会被调用，所以只有注册了的Bean才会被RPC的请求调用到。然后，通过请求中的类、方法、参数，反射调用对应的Bean，拿到结果之后，通过序列化层，封装好结果报文，服务端的通信层将报文反馈给调用方，调用方解析到返回值，动态代理类返回结果，调用结束。

4.一个完整的RPC调用反馈链条就完成了。

7.http + restful 和 RPC的区别？各自适用的场景？

RPC和restful的区别

RPC的优势：

1. 查找更具精确性，快速性，短路径，和确定性，因为属于内网查询，独立的注册中心，所以查找的速度更快。
2. 而且由于做了精简和优化，删去了RESTful方式里面很多多余的信息，比如Header，而且做了压缩和序列化，通过二进制方式传输，传输的内容更少，传输的速度也更快。
3. 环节和流程更少，因为restful需要经过路由，负载均衡，网关，防火墙和一系列的身份识别和校验， 而RPC就省去了这些环节，不需要每次核实信息，RPC省去了很多环节。

restful的优势：

1. 通用性更好，RESTful可以供任何接入互联网的终端调用，各种平台，各种终端都可以用RESTful传输和交换数据，而且有一套标准和规范的传输格式，所以格式更加标准化和通用化。
2. 安全性更高，因为属于连接外围和内网的通道，所以会经过一些列的安全和身份校验。
3. 移植性更好，从一个服务器迁移到另一个服务器，从一个节点迁移到另一个节点，从一个架构移植到另一种架构，都可以轻松完成。

应用场景

RPC的应用场景：当框架和语言种类也比较多，内部之间调用量非常大的时候，RPC是最佳的选择。RPC更多是内网之间的数据传输，一般是部署在服务层的分布式系统里面，或者微服务系统。有服务治理，服务限流、服务降级、服务熔断、服务监控等等，类似于大楼里面配了治安处，物业处、后勤处、监控中心等。

restful的应用场景：数据更多是公网上的传输，比如服务端API供 IOS、Android、PC等客户端调用， API供第三方合作方调用等 。

8.DNS协议用到了什么传输层协议？

（一台新电脑如何获取到有效的网关地址）

从依赖关系的角度看，DNS既可以基于TCP，也可以基于UDP，常用的是UDP，服务器则使用知名端口53。
DNS对UDP或TCP的使用有以下原则：

1. 使用A查询请求某个域名对应的IP地址时使用UDP；
2. 如果响应报文长度大于512字节，则UDP仅返回前512字节，并设置报文首部“参数”字段的“截断”位。客户在收到这个响应后，会使用TCP重新发送原来的请求；
3. 如果一次查询的名字很多，则客户可能会直接使用TCP
4. 在主域名服务器和辅助域名服务器之间进行区域传送时，使用TCP。

从以上原则可看出，在决定使用TCP还是UDP时，依据的是这两个协议的特征。

9.在浏览器中输入一个url，敲下回车之后发生的事情

（考虑DNS解析，负载均衡，建立连接等等）

1.URL 解析：地址解析，HSTS，其他操作，检查缓存
2.DNS 查询：

1. 浏览器缓存：浏览器会先检查是否在缓存中，没有则调用系统库函数进行查询。
2. 操作系统缓存：操作系统也有自己的 DNS缓存，但在这之前，会向检查域名是否存在本地的 Hosts 文件里，没有则向 DNS 服务器发送查询请求。
3. 路由器缓存路由器也有自己的缓存。
4. ISP DNS 缓存：ISP DNS 就是在客户端电脑上设置的首选 DNS 服务器，它们在大多数情况下都会有缓存。
5. 在前面所有步骤没有缓存的情况下，本地 DNS 服务器会将请求转发到互联网上的根域，根域名服务器查询

3.TCP 连接：
4.处理请求：
5.接受响应：
6.渲染页面：

10.服务端出现大量TIME_WAIT是什么原因导致的？

TIME_WAIT状态是什么？

TIME_WAIT状态是主动关闭TCP连接的一方（即先发起FIN包的一方），在发送完最后一个ACK包后进入的状态。系统需要在TIME_WAIT状态下等待2MSL（maximum segment lifetime ）后才能释放连接（端口）。根据RFC 793 MSL是2分钟，一般的TCP实现有30秒、1分钟和2分钟不等。

TIME_WAIT状态存在的理由：
1.可靠地实现TCP全双工连接的终止
在进行关闭连接四次挥手协议时，最后的ACK是由主动关闭端发出的，如果这个最终的ACK丢失，服务器将重发最终的FIN。 因此客户端必须维护状态信息允许它重发最终的ACK。如果不维持这个状态信息，那么客户端将响应RST分节，服务器将此分节解释成一个错误（在java中会抛出connection reset的SocketException)。
因而，要实现TCP全双工连接的正常终止，必须处理终止序列四个分节中任何一个分节的丢失情况，主动关闭的客户端必须维持状态信息进入TIME_WAIT状态。

2.允许老的重复分节在网络中消逝
TCP分节可能由于路由器异常而“迷途”，在迷途期间，TCP发送端可能因确认超时而重发这个分节，迷途的分节在路由器修复后也会被送到最终目的地，这个原来的迷途分节就称为lost duplicate。在关闭一个TCP连接后，马上又重新建立起一个相同的IP地址和端口之间的TCP连接，后一个连接被称为前一个连接的化身（incarnation)，那么有可能出现这种情况，前一个连接的迷途重复分组在前一个连接终止后出现，从而被误解成从属于新的化身。
为了避免这个情况，TCP不允许处于TIME_WAIT状态的连接启动一个新的化身，因为TIME_WAIT状态持续2MSL，就可以保证当成功建立一个TCP连接的时候，来自连接先前化身的重复分组已经在网络中消逝。

服务端出现大量TIME_WAIT原因：
一般情况下主动正常关闭TCP连接，都会出现TIMEWAIT

在高并发短连接的TCP服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。

如何尽量处理TIMEWAIT过多?
编辑内核文件/etc/sysctl.conf，加入以下内容：

net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。
net.ipv4.tcp_fin_timeout 修改系默认的 TIMEOUT 时间
然后执行 /sbin/sysctl -p 让参数生效.

/etc/sysctl.conf是一个允许改变正在运行中的Linux系统的接口，它包含一些TCP/IP堆栈和虚拟内存系统的高级选项，修改内核参数永久生效。

简单来说，就是打开系统的TIMEWAIT重用和快速回收。

11.http的报文结构？TCP的？IP的？

http

TCP

首部

IP

12.http协议的发展历程

HTTP/0.9版本

1. 首先它只有一个命令GET
2. 没有HEADER等描述数据的信息。因为这个时候的请求非常简单，它需要达到的目的也非常简单，没有那么多数据格式。
3. 服务器发送完内容之后，就关闭TCP连接

HTTP/1.0版本

1. 增加了很多命令。比如：POST、PUT、HEADER这些命令。
2. 增加了status code和header相关的内容。status code是用来描述服务器端处理某一个请求之后的状态的；header主要包含：请求和发送数据的描述以及对这部分数据进行操作的方法。
3. 增加了多字符集支持、多部分发送、权限、缓存等相关的内容。这些内容有利于更好地使用http请求去实现WEB服务。

HTTP/1.1版本
这个版本是在HTTP/1.0的基础上增加了一些功能来优化网络连接的过程。

1. 持久连接。
2. 增加了pipeline。可以在同一个TCP连接里面发送多个http请求，服务器端对于进来的请求，是要按照顺序进行数据返回的。
3. 增加了HTTP的头host和其他一些命令。其中比较重要的就是host，有了host之后就可以在同一台服务器(物理服务器)上同时跑多个web服务。

HTTP/2.0版本

1. 所有数据都是以二进制进行传输的
2. 新增头信息压缩以及推送等功能，提高了传输效率