一：对五层网络协议体系结构的概述
1.应用层：通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如域名系统DNS，支持万维网应用的HTTP协议，支持电子邮件的SMTP协议等等。我们把应用层交互的数据单元称为报文。
2.传输层：负责向两台主机进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。“通用的”是指并不针对某一个特定的网络应用，而是多个应用可以使用同一个传输层服务。
由于一台主机可同时运行多个线程，因此传输层有复用和分用的功能。所谓复用就是指多个应用层进程可同时使用下面传输层的服务；分用是运输层把收到的信息分别交付上面应用层中的想用进程。
3.网络层：在计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路。也可能还要经过很多通信子网，网络层的任务就是就是选择合适的网间路由和交换节点，确保数据及时传送。在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在TCP/IP体系结构中，由于网络层使用IP协议，因此分组也叫IP数据报，简称数据报。
4.数据链路层：两个主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。在两个相邻节点之间传送数据时，数据链路层将网络层的IP数据报组装成帧，在两个相邻节点间的链路上传送帧。每一个帧包括数据和必要的控制信息（如：同步信息，地址信息，差错控制等）。
在接收数据时，控制信息使接收端能够知道一个帧从哪个比特开始和到哪个比特结束。这样，数据链路层在收到一个帧后，就可从中提取数据部分，上交给网络层。控制信息还使接收端能够检测到所收到的帧中有无差别。如果发生差错，数据链路层就简单地丢弃这个出了差错的帧，以避免继续在网络中传输下去白白浪费网络资源。如果需要改正数据在链路层传输时出现差错，那么就要采用可靠性传输协议来纠正出现的差错。这种方法会使链路层的协议复杂些。
5.物理层：在物理层上所传送的数据单位是比特。物理层的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。使其上面的数据链路层不必考虑网络的具体传输介质是什么。
二：ARP协议的工作原理
网络层的ARP协议完成了IP地址与物理地址的映射。首先，每台主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址的对应关系。当源主机需要将一个数据包发送到目的主机时，会首先检查自己ARP列表中是否存在该IP地址对应的MAC地址；如果有，就直接将数据包发送到这个MAC地址；如果没有，就向本地网段发送一个ARP请求的广播包，查询此目标主机对应的MAC地址。
此 ARP 请求数据包里包括源主机的 IP 地址、硬件地址、以及目的主机的 IP 地址。网络中所有的主机收到这个 ARP 请求后，会检查数据包中的目的 IP 是否和自己的 IP 地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中，如果 ARP 表中已经存在该 IP 的信息，则将其覆盖，然后给源主机发送一个 ARP 响应数据包，告诉对方自己是它需要查找的 MAC 地址；源主机收到这个 ARP 响应数据包后，将得到的目的主机的 IP 地址和 MAC 地址添加到自己的 ARP 列表中，并利用此信息开始数据的传输。如果源主机一直没有收到 ARP 响应数据包，表示 ARP 查询失败。
三：IP地址分类
IP地址是指互联网协议地址，是IP协议提供的一种统一的地址格式，它为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。IP地址编址方案将IP地址空间划分为A、B、C、D、E五类，其中A、B、C是基本类，D、E类作为多播和保留使用，为特殊地址。
每个IP地址包括两个标识码，即网络标识和主机标识。同一个物理网络上的所有主机都使用同一个网络ID。
四：TCP的主要特点
1.TCP是面向连接的。（就好像打电话一样，通话前需要先拨号建立连接，通话结束后要挂机释放连接）；
2.每一个TCP连接只能有两个端点，每一条TCP连接只能是点对点的（一对一）；
3.TCP提供可靠交付的服务。通过TCP连接传送的数据，无差错、不丢失、不重复、按序到达；
4.TCP提供全双工通信。TCP允许通信双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双方通信的数据；
5.面向字节流。TCP中的“流”指的是流入进程或从进程流出的字节序列。“面向字节流”的含义是：虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。
五：UDP的主要特点
1.UDP是无连接的，面向报文的；
2.UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送频率降低（对实时应用很有用，如直播，视频会议等）；
3.UDP支持一对一、一对多、多对一和多对多的交互通信；
4.UDP的首部开销小，只有8个字节，比TCP的20个字节的首部要小。
六：三次握手
TCP建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个TCP报文段。
最初客户端和服务器都处于CLOSED（关闭）状态。本例中A（Client）主动打开连接，B（Server）被动打开连接。
一开始，B的TCP服务器进程首先创建传输控制块TCB，准备接受客户端进程的连接请求。然后服务器进程就处于LISTEN状态，等待客户端的连接请求。如有，立即做出响应。
第一次握手：A的TCP客户端也是首先创建传输控制块TCB。然后，在打算建立TCP连接时，向B发送连接请求报文段，这时首部中的同步位SYN = 1，同时选择一个初始序号seq = x。TCP规定，SYN报文段（即SYN = 1 的报文段）不能携带数据，弹药消耗掉一个序号。这是,TCP客户端进入SYN-SENT（同步已发送）状态。
第二次握手：B收到连接请求后,如果同意建立连接,则向A发送确认。在确认报文段中应把SYN位和ACK位都置为1，确认号是ack = x + 1，同时也为自己选择一个初始序号seq = y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。这时TCP服务端进程进入SYN-RCVD（同步收到）状态。
第三次握手：TCP 客户进程收到 B 的确认后，还要向 B 给出确认。确认报文段的 ACK 置 1，确认号 ack = y + 1，而自己的序号 seq = x + 1。这时 ACK 报文段可以携带数据。但如果不携带数据则不消耗序号，这种情况下，下一个数据报文段的序号仍是 seq = x + 1。这时，TCP 连接已经建立，A 进入 ESTABLISHED（已建立连接）状态。
七：为什么不是两次握手
为了防止已经失效的连接请求报文段突然又传送到了B，因而产生错误。比如下面这种情况：A发出的第一个连接请求报文段并没有丢失，而是在网络节点长时间滞留了，以至于延误到连接释放以后的某个时间段才到达B。本来这是一个早已失效的报文段。但是B收到此失效的链接请求报文段后，就误以为A又发出一次新的连接请求，于是就向A发出确认报文段，同意建立连接。
对于上面这种情况，如果不进行第三次握手，B发出确认后就认为新的运输连接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。
八：为什么不需要四次握手
有人可能会说A发出第三次握手的信息后在没有收到B的请求及已经进入到了连接状态，那如果A的这个确认包丢失或者滞留了怎么办？
我们需要明白一点，完全可靠的通信协议是不存在的。在经过三次握手之后，客户端和服务器已经可以确认之前的通信状况，都收到了确认信息。所以即便再增加握手次数也不能保证后面的通信完全可靠，所以是没有必要的。
九：Server端在收到Client端的SYN后，为什么还要传回SYN？
接收端传回发送端所发送的SYN是为了告诉发送端，我收到的信息确实是你所发送的信号了。
SYN是TCP/IP建立时使用的握手信号。在C/S之间建立正常的TCP网络连接时，客户端首先发送一个SYN消息，服务器使用SYN-ACK应答表示接收到了这个消息。
十：传了SYN，为什么还要传ACK？
双方通信无误必须是两者互相发送信息都无误。传了SYN，证明发送方到接收方的通道没有问题，但是接收方到发送方的通道还需要ACK信号进行验证。
十一：通信结束后TCP四次挥手的过程
第一次挥手：A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。A把连接释放报文段首部的终止控制位FIN置1，其序号seq = u（等于前面已传送过的数据的最后一个字节的序号加1），这时A进入FIN-WAIT-1（终止等待1）状态，等待B的确认。
注意：TCP规定，FIN报文段即使不携带数据，也将消耗掉一个序号。
第二次挥手：B收到连接释放报文段后立即发出确认，确认号是ack = u + 1，而这个报文段自己的序号是v（等于B前面已经传送过的数据的最后一个字节的序号加1），然后B就进入CLOSEWAIT（关闭等待）状态。TCP服务端进程这时应通知高层应用进程，因而从A到B这个方向的连接就释放了，这时的TCP连接处于半关闭（half-close）状态，即A已经没有数据
要发送了，但B若发送数据，A仍要接收。也就是说，从B到A这个方向的连接并未关闭，这个状态可能会持续一段时间。A收到来自B的确认后，就进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。
第三次挥手：若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接。这时B发出的连接释放报文段必须使FIN = 1。假定B的序号为w（在半关闭状态，B可能又发送一些数据）。B还必须重复上次已发送过的确认号ack = u + 1.这时B就进入LAST-ACK（最后确认）状态，等待A的确认。
第四次挥手：A在收到B的连接释放报文后，必须对此发送确认。在确认报文段中把ACK置1，确认号ack = w + 1，而自己的序号seq = u + 1（前面发送的FIN报文段要消耗一个序号）。然后进入TIME-WAIT（时间等待）状态。请注意，现在TCP连接还没有释放掉。必须经过时间等待近十期设置的时间2MSL（MSL：最长报文段寿命）后，A才能进入到CLOSED状态，然后撤销传输控制块，结束这次TCP连接。当然如果B一收到A的确认就进入CLOSED状态，然后撤销传输控制块。所以在释放连接时，B结束TCP连接的时间要早于A。
十二：为什么TIME-WAIT状态必须等待2MSL的时间呢？
为了保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN-ACK报文段的确认。B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN + ACK 报文段。接着A重传一次确认，重新启动2MSL计时器。最后，A和B都正常进入到CLOSED状态。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后立即释放连接，那么就无法收到B重传的FIN + ACK 报文段，因为也不会在发送一次确认报文段，这样，B就无法按照正常步骤进入CLOSED状态。
十三：为什么第二次跟第三次不能合并，第二次和第三次之间的等待是什么？
当服务器执行第二次挥手之后，此时证明客户端不会再向服务端请求任何数据，但是服务端可能还在给客户端发送数据（可能是客户端上一次请求的资源还没有发送完毕），所以此时服务端会等待把之前未传输完的数据传输完毕之后再发送请求。
十四：保活计时器的作用？
除时间等待计时器外，TCP还有一个保活计时器（keepalive timer）。设置这样的场景：客户已主动与服务器建立了TCP连接。但后来客户端的主机突然发生故障。显然，服务器以后进不能再收到客户端发来的数据。因此，应当有措施使服务器不要在白白等待下去。这就需要使用保活计时器了。
服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两个小时。若两个小时都没有收到客户端的数据，服务端就发送一个探测报文段，以后则每隔75s发送一次。若连续发送10个探测报文段后仍然无客户端的响应，服务端就认为客户端出了故障，接着就关闭这个连接。
十五：TCP协议是如何保证可靠传输的？
1.数据包校验：目的时检测数据在传输过程中的任何变化，若效验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据段超时会重发数据；
2.对失序数据包重排序：既然TCP报文段作为IP数据报来传输，而IP数据包的达到可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层；
3.丢失重复数据：对于重复数据，能够丢弃重复数据；
4.应答机制：当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
5.超时重发：当TCP发出一个段后，它启动一个定时器，等待目的端收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
6.流量控制：TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。
十六：谈谈你对停止等待协议的理解？
停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组；在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。主要包括以下几种情况：无差错情况、出现差错情况（超时重传）、确认丢失和确认迟到。
十七：自动重传请求ARQ协议
停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为自动重传请求ARQ。
十八：连续ARQ协议
连续ARQ协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。
十九：谈谈你对滑动窗口的了解？
TCP利用滑动窗口实现流量控制的机制。滑动窗口是一种流量控制技术。早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，同时发送数据，导致中间节点阻塞掉包，谁也发不了数据，所以就有了滑动窗口机制来解决此问题。
TCP中采用滑动窗口来进行传输控制，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。当滑动窗口为0时，发送方一般不能再发送数据报，但有两种情况除外，一种情况是可以发送紧急数据，例如，允许用户终止在远端机上的运行进程。另一种情况是发送方可以发送一个1字节的数据报来通知接收方重新声明它希望接收的下一个字节及发送方的滑动窗口大小。
二十：谈下你对流量控制的理解？
TCP利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为0，则发送方不能发送数据。
二十一：谈下你对TCP拥塞控制的理解？使用了哪些算法？
拥塞控制和流量控制不同，前者是一个全局性的过程，而后者指点对点通信量的控制。在某段时间，若对网络中某一个资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。
拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致于过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制使一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便接收端来得及接收。
为了进行拥塞控制，TCP发送方要维持一个拥塞窗口（cwnd）的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化，发送方让自己的发送窗口取为拥塞窗口和接收方的接收窗口中较小的一个。
TCP的拥塞控制采用了四种算法，即：慢开始、拥塞避免、快重传和快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如：主动队列管理AQM），以减少网络拥塞的发生。
• 慢开始：慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的负荷情况。经验标明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1，每经过一个传播轮次，cwnd加倍。
• 拥塞避免：拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT就把发送方的cwnd加1。
• 快重传和快恢复：在TCP/IP中，快重传和快恢复（FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。
没有FRR，如果数据包丢失了，TCP将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。
有了FRR，就不会因为重传时要求的暂停被耽搁。当有单独的数据包丢失时，快速重传和快恢复能有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。
二十二：什么是粘包？
如果客户端连续不断的向服务器发送数据包时，服务器接收的数据会出现两个数据包粘在一起的情况。
1. TCP是基于字节流的，虽然应用层和TCP传输层之间的数据交互是大小不等的数据块，但是TCP把这些数据块仅仅看成一连串无结构的字节流，没有边界；
2. 从TCP的帧结构也可以看出，在TCP的首部没有表示数据长度的字段。
基于上面两点，在使用TCP传输数据时，才有粘包或者拆包现象发生的可能。一个数据包中包含了发送端发送的两个数据包的信息，这种现象即为粘包。
接收方收到了两个数据包，但是这两个数据包要么是不完整的，要么就是多出来一块，这种情况即发生了拆包和粘包。拆包和粘包的问题导致接收端在处理的时候会非常困难，因为无法区分一个完整的数据包。
二十三：TCP粘包时怎么产生的？
• 发送方产生粘包
采用TCP协议传输数据的客户端与服务器经常是保持一个长连接的状态（一次连接发一次数据不存粘包），双方在连接不断开的情况下，可以一直传输数据。但当发送的数据包过于小时，那么TCP协议默认的会启动Nagle算法，将这些较小的数据包进行合并发送（缓冲区数据发送是一个堆压的过程）；这个合并过程就是在发送缓冲区中进行的，也就是说数据发送出来它已经是粘包的状态了。
• 接收方产生粘包
接收方采用TCP协议接收数据时的过程是这样的：数据到接收方，从网络模型的下方传递至传输层，传输层的TCP协议处理是将其放置接收缓冲区，然后由应用层来主动获取。这时会出现一个问题，如果我们在程序中调用的读取数据函数不能及时的把缓冲区中的数据拿出来，而下一个数据又到来并有一部分放入的缓冲区末尾。等我们读取数据时就是一个粘包。（放数据的速度 > 应用层拿数据速度）。
二十四：怎么解决拆包和粘包？
分包机制一般有两个通用的解决方法：
1. 特殊字符控制；
2. 在包头首部添加数据包的长度。
如果使用netty的话，就有专门的编码器和解析器解决拆包和粘包问题了。
提示：UDP没有粘包问题，但是有丢包和乱序。不完整的包是不会有的，收到的都是完整正确的包。传送的数据单位协议是UDP报文或用户数据报，发送的时候即不合并，也不拆分。