网络-常见JAVA面试知识点

网络

TCP

概念

序列号seq：占4个字节，用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生；给字节编上序号后，就给每一个报文段指派一个序号；序列号seq就是这个报文段中的第一个字节的数据编号

确认号ack：占4个字节，期待收到对方下一个报文段的第一个数据字节的序号；序列号表示报文段携带数据的第一个字节的编号；而确认号指的是期望接收到下一个字节的编号；因此当前报文段最后一个字节的编号+1即为确认号

确认ACK：占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效

同步SYN：连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1，握手完成后SYN标志位被置0

终止FIN：用来释放一个连接。FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接

ACK、SYN和FIN这些大写的单词表示标志位，其值要么是1，要么是0；ack、seq小写的单词表示序号

分支主题

TCP三次握手

第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手

TCP四次挥手

第一次挥手：客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号

第二次挥手：服务器收到客户端的后，发出ACK=1确认标志和客户端的确认号ack=u+1，自己的序列号seq=v，进入CLOSE-WAIT状态，TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间

第三次挥手：客户端收到服务器确认结果后，进入FIN-WAIT-2状态，，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，确认标志ACK=1，确认序号ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，如果此时序号seq=w，服务器进入LAST-ACK（最后确认态），等待客户端的确认

第四次挥手：客户端收到回复后，发送确认ACK=1，ack=w+1，自己的seq=u+1，客户端进入TIME-WAIT（时间等待）。客户端经过2个最长报文段寿命后，客户端CLOSE，此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接，服务器结束TCP连接的时间要比客户端早一些

常见问题

为什么连接的时候是三次握手，关闭的时候却是四次握手

因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假想网络是不可靠的，有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接

为什么不能用两次握手进行连接？

3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁

为什么是三次，不是两次或者四次

如果两次，那么服务端无法确定服务端的信息客户端是否能收到，所以如果服务端先发信息，可能后面的客户端都收不到，会出现问题

如果四次，那么就造成了浪费，因为在三次结束之后，就已经可以保证客户端可以给服务端发信息，并且客户端可以收到服务端的信息； 服务端可以给客户端发信息，服务端可以收到客户端的信息

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接

TCP 粘包/拆包

数据传输过程中的三种结果

一种是正常的字符串输出。

一种是多个字符串“粘”在了一起，我们定义这种 ByteBuf 为粘包。

一种是一个字符串被“拆”开，形成一个破碎的包，我们定义这种 ByteBuf 为半包。

原因

应用层面使用了Netty，但是对于操作系统来说，只认TCP协议，尽管我们的应用层是按照 ByteBuf 为 单位来发送数据，server按照Bytebuf读取，但是到了底层操作系统仍然是按照字节流发送数据，因此，数据到了服务端，也是按照字节流的方式读入，然后到了 Netty 应用层面，重新拼装成 ByteBuf，而这里的 ByteBuf 与客户端按顺序发送的 ByteBuf 可能是不对等的。因此，我们需要在客户端根据自定义协议来组装我们应用层的数据包，然后在服务端根据我们的应用层的协议来组装数据包，这个过程通常在服务端称为拆包，而在客户端称为粘包

拆包和粘包是相对的，一端粘了包，另外一端就需要将粘过的包拆开，发送端将三个数据包粘成两个 TCP 数据包发送到接收端，接收端就需要根据应用协议将两个数据包重新组装成三个数据包

解决

在没有 Netty 的情况下，用户如果自己需要拆包，基本原理就是不断从 TCP 缓冲区中读取数据，每次读取完都需要判断是否是一个完整的数据包 如果当前读取的数据不足以拼接成一个完整的业务数据包，那就保留该数据，继续从 TCP 缓冲区中读取，直到得到一个完整的数据包。 如果当前读到的数据加上已经读取的数据足够拼接成一个数据包，那就将已经读取的数据拼接上本次读取的数据，构成一个完整的业务数据包传递到业务逻辑，多余的数据仍然保留，以便和下次读到的数据尝试拼接

Netty中，已经造好了许多类型的拆包器，我们直接用就好

选好拆包器后，在代码中client段和server端将拆包器加入到chanelPipeline之中就好了

Netty

零拷贝

传统的零拷贝指的是数据传输过程中，不需要CPU进行数据的拷贝。主要是数据在用户空间与内核中间之间的拷贝

在发送数据的时候，传统的实现方式是1. `File.read(bytes)`2. `Socket.send(bytes)

这种方式需要四次数据拷贝和四次上下文切换

1. 数据从磁盘读取到内核的read buffer

2. 数据从内核缓冲区拷贝到用户缓冲区

3. 数据从用户缓冲区拷贝到内核的socket buffer

4. 数据从内核的socket buffer拷贝到网卡接口的缓冲区

第二步和第三步是没有必要的，通过java的FileChannel.transferTo方法，可以避免上面两次多余的拷贝

2. 接着DMA从内核read buffer将数据拷贝到网卡接口buffer

Netty中的零拷贝

Netty中也用到了FileChannel.transferTo方法，所以Netty的零拷贝也包括操作系统级别的零拷贝。除此之外，在ByteBuf的实现上，Netty也提供了零拷贝的一些实现

ByteBuffer接口

1. ByteBuf

1. Heap ByteBuf:直接在堆内存分配

2. Direct ByteBuf：直接在内存区域分配而不是堆内存

直接在内存区域分配空间，而不是在堆内存中分配。如果使用传统的堆内存分配，当我们需要将数据通过socket发送的时候，就需要从堆内存拷贝到直接内存，然后再由直接内存拷贝到网卡接口层。

Netty提供的直接Buffer，直接将数据分配到内存空间，从而避免了数据的拷贝，实现了零拷贝

3. CompositeByteBuf：组合Buffer

传统的ByteBuffer，如果需要将两个ByteBuffer中的数据组合到一起，我们需要首先创建一个size=size1+size2大小的新的数组，然后将两个数组中的数据拷贝到新的数组中。但是使用Netty提供的组合ByteBuf，就可以避免这样的操作，因为CompositeByteBuf并没有真正将多个Buffer组合起来，而是保存了它们的引用，从而避免了数据的拷贝，实现了零拷贝

2. ByteBufHolder

总结

Netty的接收和发送ByteBuffer采用DIRECT BUFFERS，使用堆外直接内存进行Socket读写，不需要进行字节缓冲区的二次拷贝。如果使用传统的堆内存（HEAP BUFFERS）进行Socket读写，JVM会将堆内存Buffer拷贝一份到直接内存中，然后才写入Socket中。相比于堆外直接内存，消息在发送过程中多了一次缓冲区的内存拷贝

Netty提供了组合Buffer对象，可以聚合多个ByteBuffer对象，用户可以像操作一个Buffer那样方便的对组合Buffer进行操作，避免了传统通过内存拷贝的方式将几个小Buffer合并成一个大的Buffer

Netty的文件传输采用了transferTo方法，它可以直接将文件缓冲区的数据发送到目标Channel，避免了传统通过循环write方式导致的内存拷贝问题

BIOBlcoking IO

客户端监听（Listen）时，Accept是阻塞的，只有新连接来了，Accept才会返回，主线程才能继续处理

读写socket时，Read是阻塞的，只有请求消息来了，Read才能返回，子线程才能继续处理

读写socket时，Write是阻塞的，只有客户端把消息收了，Write才能返回，子线程才能继续读取下一个请求

传统的BIO模式下，从头到尾的所有线程都是阻塞的，这些线程就干等着，占用系统的资源，什么事也不干

问题

带宽

资源

每个请求过来开一个线程阻塞

NIO

仅在select的时候阻塞

网络模型

select

遍历，判断事件是否可达，然后继续

poll

poll是对select的一次改进，但是遍历FD方式是一致的在用户调用selector.selectedKeys()的时候，操作系统扫描所有socket，从系统内核复制到用户的内存。随着连接数的增长，遍历、复制的时间线性增长，并且消耗内存随之增大

epoll

epoll的模式仅关心活跃的部分，减少遍历和复制操作

监视的描述符数量不受限制

I/O效率不会随着FD数目的增加而线性下降，epoll不同于select和poll轮询的方式，而是通过每个fd定义的回调函数来实现的。通过事件驱动的方式，只有就绪的fd才会执行回调函数

使用mmap加速内核与内存用户空间的消息传递，epoll通过系统内核和用户空间使用mmap（共享内存的方式）来实现

本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间

在 select/poll中，进程只有在调用一定的方法后，内核才对所有监视的文件描述符进行扫描，而epoll事先通过epoll_ctl()来注册一 个文件描述符，一旦基于某个文件描述符就绪时，内核会采用类似callback的回调机制，迅速激活这个文件描述符，当进程调用epoll_wait() 时便得到通知。(此处去掉了遍历文件描述符，而是通过监听回调的的机制，这正是epoll的魅力所在。)

IO多路复用

事件机制

用一个线程把Accept，读写操作，请求处理的逻辑全干了。如果什么事都没得做，它也不会死循环，它会将线程休眠起来，直到下一个事件来了再继续干活，这样的一个线程称之为NIO线程

while true { events = takeEvents(fds) // 获取事件，如果没有事件，线程就休眠 for event in events { if event.isAcceptable { doAccept() // 新链接来了 } elif event.isReadable { request = doRead() // 读消息 if request.isComplete() { doProcess() } } elif event.isWriteable { doWrite() // 写消息 } }}

组件

Channel：Channel保存了socket连接的有关信息，以及ChannelPipeLine（串起ChannelHandlerContext）/Unsafe（实现底层传输）/EventLoop（对应一个IO线程）/SelectionKey（如果为NIO模式，标识该Channel此时的连接读写事件）等有效信息，NIO服务端负责响应连接的是NioServerSocketChannel，客户端为NioSocketChannel

Buffer：缓冲区，用于和NIO Channel交互，从Channel中读取数据到Buffer，从Buffer将数据写入到Channel

Selector：Selector是Java NIO提供的多路复用器，负责配合操作系统的select/epoll操作将就绪的IO事件分离出来，落地为SelectionKey，我们可以将SelectionKey看做Reactor模式中的资源实现一个线程就能监听多个Channel（Channel需先register到Selector）的读写等状态，然后触发ChannelPipeLine的fireChannelRead操作（串行ChannelHandlerContext持有的ChannelHandler）/底层Channel的数据写入（数据来源于Buffer）

EventLoop/EventLoopGroup，EventLoopGroup其实就是一个EventLoop线程组，netty中通常有多个EventLoop同时工作，每个EventLoop维护着一个Selector实例（类似单线程Reactor工作）。如果没有显式指定，默认每个EvenLoopGroup中的线程数为可用的CPU内核数*2通常每个netty服务端有两个EventLoopGroup：bossGroup和workerGroupbossGroup用作Acceptor线程池，负责处理客户端的连接请求，通常一个服务端口对应一个EventLoop线程，根据实际需要配置线程组的线程数量。Acceptor线程通过不断轮询Selector上的Accept事件，将accept的SocketChannel交给另外一个EventLoop线程组。如果系统只有一个服务端端口需要监听，则建议 bossGroup 线程组线程数设置为 1workerGroup会根据线程组的顺序next一个可用的EventLoop将这个SocketChannel注册到其维护的Selector上，并处理其后续的I/O的事件，是真正负责 I/O 读写操作的线程组，通过 ServerBootstrap 的 group 方法进行设置，用于后续的 Channel 绑定

ChannelPipleline，每个SocketChannel都有一个Pipleline实例，而每个Pipleline中维护了一个ChannelHandler链表队列。Pipleline和ChannelHandler的关系类似servlet和filter过滤器的作用。EventLoop从Selector中分离出就绪的channel以后，会将它传递的消息传输到Pipleline中，通过ChannelHandler处理链进行层层处理，用户可以在Handler中添加自己的业务逻辑。ChannelPipleline中本身维护着两个不可见的HeadHandler和TailHandler，head靠近网络层，tail靠近用户。netty中有两类事件类型，inbound和outbound。inbound可以理解为从网络数据外部流向内部，如读取消息；outbound为网络数据从内部流向外部，如写消息。Pipleline会根据事件的类型， 自上而下或自下而上调用事件相关联的ChannelHandler对消息进行处理。如读取消息的时候会依次执行HeadHandler、ChannelHandler1...ChannelHandlerN、TailHandler

AIO

架构

执行链路

服务端

1、创建ServerBootStrap实例

2、设置并绑定Reactor线程池：EventLoopGroup，EventLoop就是处理所有注册到本线程的Selector上面的Channel

3、设置并绑定服务端的channel

4、5、创建处理网络事件的ChannelPipeline和handler，网络时间以流的形式在其中流转，handler完成多数的功能定制：比如编解码 SSl安全认证

6、绑定并启动监听端口

7、当轮询到准备就绪的channel后，由Reactor线程：NioEventLoop执行pipline中的方法，最终调度并执行channelHandler 

客户端

Reactor线程模型

一个NIO线程+一个accept线程：

Reactor多线程模型

Reactor主从模型

Netty是建立在NIO基础之上，Netty在NIO之上又提供了更高层次的抽象在Netty里面，Accept连接可以使用单独的线程池去处理，读写操作又是另外的线程池来处理Accept连接和读写操作也可以使用同一个线程池来进行处理。而请求处理逻辑既可以使用单独的线程池进行处理，也可以跟放在读写线程一块处理。线程池中的每一个线程都是NIO线程。用户可以根据实际情况进行组装，构造出满足系统需求的高性能并发模型

原生JDK的问题

1、API复杂

2、对多线程很熟悉：因为NIO涉及到Reactor模式

3、高可用的话：需要出路断连重连、半包读写、失败缓存等问题

4、JDK NIO的bug