【面试题】计算机网络

时间 2019-11-26

原文原文链接

一、TCP拥塞如何控制？

（1）滑动窗口：TCP中采用滑动窗口来进行传输控制，滑动窗口的大小意味着接收方还有多大的缓冲区能够用于接收数据html

　　滑动窗口存在于数据链路层（针对于帧的传送）和传输层（针对字节数据的传送），二者有不一样的协议，但基本原理是相近的。linux

滑动窗口指出接收缓冲区中的可用空间，从而确保发送方发送的数据不会溢出缓冲区。算法

窗口时刻动态变化：当接收发送发数据时，窗口大小减少；当接收方从缓冲区中读取数据时，窗口大小增大。编程

TCP的接收缓冲区满，它必须等待应用程序从这个缓冲区读取数据后才能再接收发送方传来的数据。segmentfault

UDP不提供流控制，按发送方的速率发送数据，无论接收方的缓冲区是否装得下。数组

## 参考文献：《UNIX网络编程》浏览器

（2）TCP拥塞的缘由：在早期的时候，通讯的双方不知道网络的情况，因此过程当中可能会出现中间节点阻塞丢包，因此就有了滑动窗口机制来解决这个问题。缓存

（3）滑动窗口协议：用于网络数据传输时的流量控制，以免拥塞的发生。若是过多的发送方同时以很快的速度发送大量的数据包，接收方有可能并无那么高的接收数据能力，所以极易致使网络的拥塞（并发服务器）。安全

　　协议中规定，对于窗口内未经确认的分组（传输中接收方必须确认收到的数据包。）须要重传。这种分组的数量最多能够等于发送窗口的大小。服务器

（4）滑动窗口的值：网络中没有出现拥塞，滑动窗口的值能够增大一些（以便把更多的数据包发送出去）；网络出现拥塞，滑动窗口的值应该减少一些（以减小注入到网络中的数据包数）

（5）拥塞控制算法：

基于丢包的拥塞控制：将丢包视为出现拥塞，采起缓慢探测的方式，逐渐增大拥塞窗口，当出现丢包时，将拥塞窗口减少，如Reno、Cubic等。
基于时延的拥塞控制：将时延增长视为出现拥塞，延时增长时增大拥塞窗口，延时减少时减少拥塞窗口，如Vegas、FastTCP等。
基于链路容量的拥塞控制：实时测量网络带宽和时延，认为网络上报文总量大于带宽时延乘积时出现了拥塞，如BBR。
基于学习的拥塞控制：没有特定的拥塞信号，而是借助评价函数，基于训练数据，使用机器学习的方法造成一个控制策略，如Remy。

## 参考文章：浅谈TCP拥塞控制算法

二、阻塞IO，非阻塞IO，同步IO，异步IO的区别？

#include <sys/types.h>
#include <sys/socket.h>
ssize_t recv(int sockfd, void *buf, size_t len, int flags);

- flags：
+ 0：默认设置，此时recv是阻塞接收的，0是常设置的值。

+ MSG_DONTWAIT：非阻塞接收

+ MSG_OOB：接收的是带外数据

+ ...：其它选项

（1）阻塞IO：使用recv的默认参数一直等数据直到拷贝到用户空间，这段时间内进程始终阻塞。

　　A从宿舍（用户空间）拿着水瓶去饮水机处（内核空间）打水，等到水打满了以后就离开了。若饮水机没有水则一直阻塞等待杯子装满水为止，才离开去作别的事情。（这种IO模型是阻塞+同步的）

（2）非阻塞IO：

　　改变flags，recv无论有没有获取到数据都返回（若是没有数据那么一段时间后再调用recv看看，如此循环）

　　B也从宿舍（用户空间）拿着水瓶去饮水机处（内核空间）打水，打开水龙头发现没有水以后离开了（回到用户空间）。

　　只有是检查无数据的时候是非阻塞的，在数据到达的时候依然要等待复制数据到用户空间(等着水将水杯装满)（这种IO模型是非阻塞+同步的）

（3）同步IO：IO多路复用（select, poll, epoll模型），监听多个IO对象，对象有变化（有数据）的时候就通知用户进程（单个进程能够处理多个socket）

　　select/epoll的优点并非对于单个链接能处理得更快，而是在于能处理更多的链接。

（4）异步IO：当进程发起IO 操做以后，就直接返回不再理睬了，直到kernel发送一个信号，告诉进程说IO完成。在这整个过程当中，进程彻底没有被block。

## 参考文章：简述同步IO、异步IO、阻塞IO、非阻塞IO之间的联系与区别（以为他写的例子特别好，拿来分享）

三、TCP怎么作到链接的？三次握手，为何不能两次握手

（1）全双工：通讯容许数据在两个方向上同时传输，它在能力上至关于两个单工通讯方式的结合。能够同时进行信号的双向传输，A→B和B→A，是瞬时同步的。

（2）TCP链接：要客户端->服务器和服务器->客户端都要创建链接

客户端向服务器发送SYN标志位 = 1，seq数据包（seq=x 随机32位序列号），进入SYN_SENT状态
服务器检测SYN的值是否为1，收到客户端链接请求。向客户端发送一个ACK标志位（=1），确认号ack=x+1；同时本身也发送一个SYN标志位=1，seq=y 即SYN+ACK包，此时服务器进入SYN_RECV状态
客户端收到服务器的的SYN+ACK包，向服务器发送一个ACK包（ACK标志位，确认号ack=y+1），序列号seq=x+1。此包发送完毕，客户端和服务器进入ESTABLISHED（TCP链接成功）状态，完成三次握手

（3）由于TCP的链接是全双工的，应用程序在任什么时候刻既能够发送数据也能够接收数据。TCP

为了实现可靠数据传输， TCP 协议的通讯双方都必须维护一个序列号，以标识发送出去的数据包中，哪些是已经被对方收到的。

三次握手的过程便是通讯双方相互告知序列号起始值，并确认对方已经收到了序列号起始值的必经步骤

若是只是两次握手，至多只有链接发起方的起始序列号能被确认，另外一方选择的序列号则得不到确认

## 参考文章：https://blog.csdn.net/lengxiao1993/article/details/82771768

四、TCP的三次握手和四次挥手

（1）三次握手同上

（2）四次挥手：

客户端中止发送数据，向服务器发送FIN包：FIN序列=1，seq=u（u=前面已经传过来的数据的最后一个字节的序号+1）。客户端进入FIN-WAIT-1状态
服务器接收到FIN包，向客户端发出确认报文ACK包：ACK=1，ack=u+1，seq=v。此时服务器进入CLOSE-WAIT（等待关闭）状态。
TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，可是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
客户端接收服务器的确认请求，客户端进入FIN-WAIT-2（终止等待1）状态，等待服务器发送FIN包（在此以前还要接收服务器发送的最后数据）
服务器将最后的数据发送完毕后，向客户端发送FIN包（FIN=1，ACK=1，ack=u+1，服务器可能又发送了一些数据seq=w），服务器进入LAST-ACK（最后确认）状态，等待客户端的确认。
客户端收到服务器的FIN包以后，必须发出确认包ACK包（ACK=1，ack=w+1，本身的序号是seq=u+1），客户端进入TIME_WAIT（时间等待）状态，此时TCP链接还未释放，必须通过2MSL后客户端撤销相应的TCP后，才进入CLOSED状态
服务器只要收到了客户端的确认包，当即进入CLOSED状态，撤销TCB以后结束了此次TCP链接。服务器向客户端的方向就被释放了。

客户端->服务器：seq=u；服务器收到谁的FIN，发送ack=u+1；

服务器->客户端：seq=v / seq = w；客户端收到谁的FIN，发送ack=w+1，再发送本身的序列号seq=u+1

（3）TCP四次挥手中TIME-WAIT和CLOSE-WAIT的区别：

　　CLOSE-WAIT：当被动关闭方接收到主动关闭方发出的FIN包，被动关闭方发出确认ACK包以后，进入CLOSE-WAIT状态，处于半关闭状态，此时主动关闭方没有数据要发送了，可是被动关闭方可能还有数据须要发送，主动关闭方必须接收它的数据。

　　TIME-WAIT：主动关闭方接收到被动关闭方发出的FIN包，向被动关闭方发出确认ACK包以后，进入TIME-WAIT状态。因为主动关闭方要等待被动关闭方接收到ACK包，报文最长的寿命时间为2MSL，若是在2MSL内被动关闭方没有接收到ACK包，会再次重发FIN包，这是一个等待机制。在通过2MSL事件后，主动关闭方才撤销TCB，进入CLOSE状态。

【报文最长的寿命时间：2MSL】　　

五、TCP和UDP

TCP：传输控制协议

UDP：用户数据报协议

须要资源少，网络状况稳定的内网，或者对于丢包不敏感的应用，好比 DHCP 就是基于 UDP 协议的。
不须要一对一沟通，创建链接，而是能够广播的应用。由于它不面向链接，因此能够作到一对多，承担广播或者多播的协议。
须要处理速度快，能够容忍丢包，可是即便网络拥塞，也绝不退缩，勇往直前的时候

TCP应用场景：

UDP应用场景：

直播：直播对实时性的要求比较高，宁肯丢包，也不要卡顿的，因此不少直播应用都基于 UDP 实现了本身的视频传输协议
实时游戏：游戏的特色也是实时性比较高，在这种状况下，采用自定义的可靠的 UDP 协议，自定义重传策略，可以把产生的延迟降到最低，减小网络问题对游戏形成的影响
物联网：一方面，物联网领域中断资源少，极可能知识个很小的嵌入式系统，而维护 TCP 协议的代价太大了；另外一方面，物联网对实时性的要求也特别高。好比 Google 旗下的 Nest 简历 Thread Group，推出了物联网通讯协议 Thread，就是基于 UDP 协议的

数据包总量比较少的通讯，好比DNS、SNMP。

视频、音频等对实时性要求比较高的多媒体通讯。

广播通讯、多播通讯。

## 参考文章： http://www.javashuo.com/article/p-kbkappoe-hc.html

六、TCP

（1）TCP如何保证可靠？

TCP给发送的每个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层
流量控制：TCP链接的每一方都有固定大小的缓冲空间，TCP的接收端只容许发送端发送接收端数据所能接收的数据量。能够下降发送的速率，防止包丢失。【滑动窗口协议】
拥塞控制：当网络拥塞时，减小数据的发送
校验和：检测数据在传输过程当中的任何变化，如何收到段的校验和有差错，TCP将丢弃这个报文段和不确认收到次报文段【TCP会丢弃重复的数据】
中止传输协议：每发完一个分组就中止发送，等待对方确认接收。在收到确认后再发送下一个分组。【超时重传：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。若是不能及时收到一个确认，将重发这个报文段。】

（2）TCP的滑动窗口影响了什么性能？

改善了网络的吞吐量：允许发送方在接收任何应答以前传送附加的包。接收方告诉发送方在某一时刻能送多少包（称窗口尺寸）。

【吞吐量：单位时间内成功地传送数据的数量】

实现流量控制：若是滑动窗口太小，则须要在网络上频繁的传输确认信息，占用了大量的网络带宽；若是滑动窗口过大，对于利用率较高，容易产生丢包现象的网络，则须要屡次发送重复的数据，也一样耗费了网络带宽

（3）TCP的粘包怎么解决？

　一、粘包：

　　应用程序所看到的数据是一个总体，或说是一个流，一条消息有多少字节对应用程序是不可见的【TCP协议是面向流的协议】，这也是容易出现粘包问题的缘由。

　　UDP是面向消息的协议，每一个UDP段都是一条消息，应用程序必须以消息为单位提取数据，不能一次提取任意字节的数据

　二、怎样定义消息：

　　能够认为一次性write/send的数据为一个消息【不管底层怎样分段分片，TCP协议层会把构成整条消息的数据段排序完成后才呈如今内核缓冲区。】

　三、出现粘包的缘由：

　　由于接收方不知道消息之间的界限，不知道一次性提取多少字节的数据所形成的。

　　1）客户端发：消息A，消息B ==> 消息A，消息B

　　2）客户端发：消息A，消息B ==> 消息A，消息A+B （消息A太大了 || 服务器不及时接收缓冲区的包，服务端下次再收的时候仍是从缓冲区拿上次遗留的数据）

　　3）客户端发：消息A，消息B ==> 消息A+B，消息B （消息A过小了，TCP为了提升传输效率，等缓冲区满才发送出去）

　　4）客户端发：消息A，消息B ==> 消息A+B（消息A和B都过小了，TCP为了提升传输效率，将消息A和B粘包一块儿发送）

四、粘包的解决方法：

接收端不知道发送端将要传送的字节流的长度，因此解决粘包的方法就是围绕，如何让发送端在发送数据前，把本身将要发送的字节流总大小让接收端知晓，而后接收端来一个死循环接收完全部数据

　　1）在两次send之间调用usleep休眠小一段时间来解决【缺点：传输效率大大下降，并且也并不可靠】

　　2）对数据包进行封包和解包：发送消息的时候，给每一个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，经过读取包首部的长度字段，便知道每个数据包的实际长度了。【缺点：会放大网络延迟带来的性能损耗】

　　3）发送端将每一个数据包封装为固定长度（不够的能够经过补0填充），这样接收端每次从接收缓冲区中读取固定长度的数据就天然而然的把每一个数据包拆分开来。

　　4）在数据包之间设置边界，如添加特殊符号，这样，接收端经过这个边界就能够将不一样的数据包拆分开。

（4）TCP为何有time_wait状态？

　　因为主动关闭方要等待被动关闭方接收到ACK包，报文最长的寿命时间为2MSL，若是在2MSL内被动关闭方没有接收到ACK包，会再次重发FIN包，这是一个等待机制。

　　在通过2MSL事件后，主动关闭方才撤销TCB，进入CLOSE状态。

（5）TCP能有多少个链接

系统用一个4四元组来惟一标识一个TCP链接：{local ip, local port,remote ip,remote port}

　　客户端（理论值）：client发起TCP请求时会绑定一个端口，该端口是独占的，不能和其余TCP链接共享

　　　　　　　　　　端口的数据结构是unsigned short，端口0不能使用，因此2¹⁶-1=65535 = TCP理论最大链接数

　　服务器端（理论值）：最大TCP链接 = 客户端IP数×客户端PORT数 ≈ 2^{32（ip最大值）} × 2^{16（port最大值)} ≈ 2⁴⁸

　　实际值：对server端，经过增长内存、修改最大文件描述符个数等参数，单机最大并发TCP链接数超过10万是没问题的

## 参考文章：http://www.javashuo.com/article/p-umwlekfk-eb.html

（6）TCP三次握手以前须要什么（ARP解析和IP寻址)

　　建立套接字【socket】，绑定端口【bind】，准备监听【listen(套接字,等待链接队列的最长长度)】

　　网络：两主机要通讯传送数据时，就要把应用数据封装成IP包，而后再交给下一层数据链路层继续封装成帧；以后根据MAC地址才能把数据从一台主机，准确无误的传送到另外一台主机。

　　　　　ARP解析：数据链路层，经过IP寻找对方的MAC地址

　　　　 IP寻址：网络层，根据目的IP地址，找到目的网络

（7）TCP第三次握手的做用是什么？

　　完成了TCP的全双工通讯链接，打通了服务器到客户端的通讯通道

（8）TCP链接创建以后呢？

　　一、TCP链接以后就能够进行通讯了，客户端到服务器端的通讯，服务器端到客户端的通讯。

　　二、链接以后网线断了：select，epoll监测不到断开或错误事件，对于服务端来讲会一直维持着这个链接。

　　　　　　若是网线断开的时间短暂，在SO_KEEPALIVE设定的探测时间间隔内，而且两端在此期间没有任何针对此长链接的网络操做。当连上网线后此TCP链接能够自动恢复，继续进行正常的网络操做。

　　　　　　若是网线断开的时间很长，超出了SO_KEEPALIVE设定的探测时间间隔，或者两端期间在此有了任何针对此长链接的网络操做。当连上网线时就会出现ETIMEDOUT或者ECONNRESET的错误。你必须从新创建一个新的长链接进行网络操做。

【　服务器要想知道客户端的意外掉线，须要作心跳包：在客户端和服务器间定时通知对方本身状态的一个本身定义的命令字，按照必定的时间间隔发送。

　　心跳包：定时发送的一个自定义结构体（心跳包或心跳帧），让对方知道本身“在线”。以确保连接的有效性。

　　TCP中已经为实现了一个叫作心跳的机制，若是设置了心跳，那TCP就会在必定的时间内发送你设置的次数的心跳，而且此信息不会影响你本身定义的协议。

应用层本身实现的心跳包：启动一个低级别的线程，在该线程中不断检测客户端的回应，若是在必定时间内没有收到客户端的回应，即认为客户端已经掉线；一样，若是客户端在必定时间内没有收到服务器的心跳包，则认为链接不可用。
TCP的KeepAlive保活机制：利用TCP／IP协议层为内置的KeepAlive功能来实现心跳功能

】　

　　三、链接以后出现服务器意外掉线之类的错误：例如Qt中监听错误信号QAbstractSocket::error(QAbstractSocket::SocketError socketError)，当链接不上服务器的时候，会发送QAbstractSocket::ConnectionRefusedError错误信号，能够进行响应的处理

（9）TCP快重传

　　发送端在发送数据包以后就开启一个计时器，在必定时间内没有收到对方的ACK报文，则从新发送数据，直到发送成功。

　　影响超时重传机制协议效率的一个关键参数是重传超时时间（RTO）。

　　RTO的值被设置过大太小都会对协议形成不利影响。

RTO设长了，重发就慢，没有效率，性能差。
RTO设短了，重发的就快，会增长网络拥塞，致使更多的超时，更多的超时致使更多的重发。

　　链接往返时间（RTT），指发送端从发送TCP包开始到接收它的当即响应所消耗的时间。

（10）TCP链接中，服务端的socket要作哪些

　　一、建立socket：int socket(int domain/*IPv4*/, int type/*子协议*/, int protocol/*协议号，通常为0*/);

　　二、绑定IP和端口号bind：int bind(int sockfd/*套接字*/, const struct sockaddr *addr/*服务器端结构体*/, socklen_t addrlen/*结构体长度*/);

出现没法绑定setsockopt：setsockopt(listenfd,SOL_SOCKET,SO_REUSEADDR,&opt/*1*/,sizoef(opt));

　　三、作监听准备listen：int listen(int sockfd/*套接字*/, int backlog/*等待队列的容量*/);

　　四、被动监听客户端的链接请求并响应accept：int accept(int sockfd/*套接字*/, struct sockaddr *addr/*客户端结构体*/, socklen_t *addrlen/*结构体长度*/);

　　五、发送数据send：ssize_t send(int sockfd/*套接字*/, const void *buf/*缓存发送的消息*/, size_t len/*缓存大小*/, int flags/*是否阻塞*/);

　　六、接收数据recv：ssize_t recv(int sockfd/*套接字*/, void *buf/*缓存接收的消息*/, size_t len/*缓存大小*/, int flags/*是否阻塞*/);

　　七、关闭TCP链接：shutdown：int shutdown(int sockfd, int how/*如何断开链接*/); /*链接就会被当即断开*/

　　　　　　　　　　 close ：int close(int sockfd); /*一次性关掉读写，没法解决多个文件描述符指向了同一个链接时的关闭*/

（11）TCP三次握手的缺点可能引发的危害？

　　在TCP三次握手的第三步中，若是服务器没有收到客户端的最终ACK确认报文，会一直处于SYN_RECV状态，将客户端IP加入等待列表，并重发第二步的SYN+ACK报文。重发通常进行3-5次，大约间隔30秒左右轮询一次等待列表重试全部客户端。另外一方面，服务器在本身发出了SYN+ACK报文后，会

预分配资源为即将创建的TCP链接储存信息作准备，这个资源在等待重试期间一直保留。更为重要的是，服务器资源有限，能够维护的SYN_RECV状态超过极限后就再也不接受新的SYN报文，也就是拒绝新的TCP链接创建。

　　一、DOS攻击：拒绝服务攻击，【服务资源包括网络带宽，文件系统空间容量，开放的进程或者容许的链接。这种攻击会致使资源的匮乏，不管计算机的处理速度多快、内存容量多大、网络带宽的速度多快都没法避免这种攻击带来的后果，使计算机或网络没法提供正常的服务】

　　　　最多见的DoS攻击有计算机网络宽带攻击和连通性攻击

- 　　基于卷：向目标发送大量数据包，从而耗尽全部资源。使用的资源可能只是带宽。这些攻击包括ICMP和UDP泛洪。
- 　　基于协议：这些攻击一般使用服务器的资源，而不是来自服务器的带宽。他们还可使用服务器外围的网络设备的资源（例如防火墙，入侵检测系统和交换机）。示例包括Smurf攻击（使用欺骗IP的广播IP的ICMP），Fraggle攻击（与Smurf相同，仅使用UDP），SYN泛洪，死亡ping（具备相同目标和源IP和端口的超大ICMP），以及好多其它的。
- 　　应用层攻击：对服务器的合法应用程序层（第7层）请求的攻击，这些请求旨在使其崩溃。其中包括对Apache HTTP Server和Microsoft IIS的攻击，还包括Slowloris等工具。

　　二、DDOS攻击：分布式拒绝服务攻击

　　指借助于客户/服务器技术，将多个计算机联合起来做为攻击平台，对一个或多个目标发动DDOS攻击，从而成倍地提升拒绝服务攻击的威力。

（12）TCP的特色

　　面向链接、可靠的字节流传输

面向链接：TCP的链接是全双工的，链接是一对一的
字节流传输：发送端执行写操做和接收端执行的读操做直接没有数量关系，TCP将数据先放入缓冲区中，这些数据有可能会粘包
可靠：发送应答机制、超时重传机制、滑动窗口机制

（13）TCP如何保证可靠有序的传输？

经过三次握手创建链接
发送应答机制，也就是将数据发送给对方后，对方必须应答是否发送成功
使用“滑动窗口”机制，根据网络的好坏，控制发送的分组数据的大小
超时重传机制，发送端在发送TCP数据包以后启动定时器，若是在时间到了还未收到应答，发送端将从新发送数据包

七、select、poll、epoll

以老师给学生回答作例子：

　　（1）循环服务器模型：服务器再同一时刻只能响应一个客户端的请求

　　　　　　　　　　例子：当一个学生来上课，老师一直跟着这名学生，直到它解决问题离开教室，老师才能一直解决下一个学生的问题。

　　　　　　　　　　　　　只要有学生进入教室，不管这名学生有没有问题，老师都不能帮助其余同窗解决问题，须要等到这名学生离开教室为止

　　　　　　　　⭐优势：简单易懂，没有同步、加锁等复杂状况，也没有进程建立等开销　　

- UDP循环服务器：每次从套接字上读取一个客户端请求->处理->而后将结果返回给客户端

　　　　　　　　　由于UDP是短链接，没有一个客户端能够一直占用服务端（文件传输除外），服务器能够知足每个客户端的请求

- TCP循环服务器：一次只能处理一个客户端的请求，完成这个客户端的全部请求后才能够断开链接，若是任务没有完成，那么它会一直占用服务器的进程，直处处理完毕以后服务器关闭链接。

　　（2）并发服务器模型：每个客户端的请求并非由服务器直接处理，并且由服务器的子进程/线程来处理，这样服务器能够在同一个时刻响应多个客户端的请求

　　　　　　　　　　例子：学校为了解决老师没法同时帮助多个学生解决问题，为每个学生安排了一名老师进行辅导，可是学校的资源有限，当学生的数量达到必定量时，学校没法承担那么大的开销。

　　　　　　　　⭐缺点：没有从根本上解决循环服务器处理效率低的问题（学校不能无限制的聘请无数个老师）

　　　　　　　　　　　　没有解决资源利用率低的问题（每位学生不可能一直有问题，可是每一个学生都占用了一名老师资源）

- 多进程并发服务器模型：改进了TCP循环服务器客户端独占服务器的状况，可是建立多个进程很是消耗资源，系统的进程数也有限制
- 多线程并发服务器模型：改进了多进程并发服务器资源消耗大的问题，可是同时也带来了同步问题，线程不健壮的问题，容易致使整个服务器的崩溃，一个进程能建立的线程数也存在上限

　　（3）I/O多路复用模型：内核一旦发现进程指定的一个或者多个IO条件准备读取时，它就通知该进程。

　　　　　　　　　　例子：因为资源利用率的问题，学校只聘请一名特别资深的教授（具备高端配置的服务器），这名教授处理问题的速度特别快

　　　　　　　　　　　　　同时安排一名班长监听每一个学生有没有问题，若是有问题，班长就告诉教授，教授就快速的解决这名学生的问题，解决以后进入等待，直到监听到下一名学生出现问题为止

　　　　　　　　　　　　　这样，每一个学生的问题都能被即时响应和解决，并且没有浪费资源

　　　　　　　　⭐优势：系统开销小，没必要建立和维护进程/线程，从而大大减少了系统的开销，同时解决了线程阻塞的问题（也可使用到并发服务器的设计中）

　　　　　【由于socket套接字也是一种文件，socket句柄就是一个文件描述符，因此能够经过数据结构存储这些文件描述符，实现通讯的需求】

- select：本质是数组【轮询 + 遍历】

　　　　　　　　⭐优势：跨平台支持性好，几乎在全部平台上都支持

　　　　　　　　⭐缺点：

1. 1. 延展性差：用数fd_set来管理文件描述符，fd_set的本质是数组，因此select监听的个数有最大值【默认1024】
  2. 数据开销大：每次调用select，都须要把fd_set从用户态拷贝到内核态，影响系统效能

- poll：本质是链表【轮询 + 遍历】

　　　　　　　　⭐优势：解决了select监听个数受限的问题

　　　　　　　　⭐缺点：须要作从用户态到内核态的转换，和数据拷贝，效率低，而后轮询每一个fd的状态，会经历屡次无谓的遍历

　　　　　　　　　　　　 没有解决select中的性能问题，须要轮询pollfd来获取就绪的文件描述符，可是同一时刻可能只有少数的客户端有请求

- epoll：本质是红黑树

　　　　　　　　⭐优势：不须要作用户区到内核去的转换，数据在共享内存中，epoll维护的红黑树在共享内存中，内核区和用户区共同操做共享内存

（1）三种多路复用IO的区别？

　　一、select内部用数组实现，poll用链表实现，epoll用红黑树来实现

　　二、select有最大监听个数的限制，poll和epoll没有

　　三、select和poll须要作从内核区到用户区的转换，数据拷贝，效率低
　　 epoll不须要，epoll维护的树及其数据都在共享内存中

## 参考资料：老梁 + 肖家宝同窗的整理 + 个人笔记

八、linux中文件IO和标准IO的区别

（1）文件IO：不带缓存的IO，也是低级IO，操做系统提供的基本IO服务【不可移植，特定于LINUX平台/UNIX平台】

（2）标准IO：是标准函数包和stdio.h头文件中定义的部分，具备可移植性，提供了三种类型的缓冲区

全缓冲区：填满缓冲区才能进行实际的IO操做，能够调用fflush()刷新【普通文件】
行缓冲区：当输入或输出遇到换行符时刷新缓冲区，标准IO库执行IO操做【标准输入输出】
无缓冲区：【stderr】

## 参考文章：https://blog.csdn.net/big_bit/article/details/51804391

九、HTTP（超文本传输协议）/ HTTPS（安全超文本传输协议）

HTTP　　

　　特色：客户端发送的每次请求都须要服务器回送响应，在请求结束后，会主动释放链接。从创建链接到关闭链接的过程称为“一次链接”。

HTTPS = HTTP over SSL/TLS

　　是一个安全通讯通道

　　HTTP是应用层协议，TCP是传输层协议，在应用层和传输层之间，增长了一个安全套接层SSL（安全套接字层）/TLS（传输层安全协议）

　　SSL使用40 位关键字做为RC4流加密算法

HTTPS的做用：

内容加密创建一个信息安全通道，来保证数据传输的安全；
身份认证确认网站的真实性
数据完整性防止内容被第三方冒充或者篡改

HTTP和HTTPS的区别：

HTTPS协议须要到CA申请证书。
HTTP是超文本传输协议，信息是明文传输；HTTPS则是具备安全性的ssl加密传输协议。
HTTP和HTTPS使用的是彻底不一样的链接方式，用的端口也不同，HTTP是80，HTTPS是443。
HTTP的链接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议安全。

## 参考文章：https://blog.csdn.net/WHB20081815/article/details/67640804

十、ARP解析过程

　　ARP：地址解析协议，ARP协议提供了网络层地址（IP地址）到物理地址（mac地址）之间的动态映射

（1）为何须要ARP协议

　　OSI模型把网络工做分为七层，每层互不干扰，只经过接口来进行通讯。IP地址在第三层网络层，MAC地址在第二层数据链路层。

　　协议在发送数据包时，数据包首先是被网卡接收到再去处理上层协议的，因此首先要封装第三层（IP地址）和第二次（MAC地址）的报头，可是协议仅知道目的地址IP地址，不知道MAC地址，可是不能跨层通讯

　　因此须要用到ARP协议

（2）工做过程：

每一个主机都会在本身的 ARP 缓冲区中创建一个 ARP 列表，以表示 IP 地址和 MAC 地址之间的对应关系。
当主机A向主机B发送数据时，先在本身的ARP缓冲表中查看有没有主机B的IP地址
如有，则直接查出主机B对应的MAC地址，直接向其发送数据
若没有，则更新本身的缓冲区，将主机B与其MAC地址的映射关系更新到本身的ARP缓冲列表中【ARP请求分组，ARP响应分组】

- 在本局域网上广播一个ARP请求分组。ARP请求分组的主要内容是代表：个人IP地址是192.168.0.2，个人硬件地址是00-00-C0-15-AD-18，我想知道IP地址为192.168.0.4的主机的硬件地址
- 在本局域网上的全部主机上运行的ARP进行都收到此ARP请求分组
- 主机B在ARP请求分组中看到本身的IP地址，就向主机A发送ARP响应分组，并写入本身的硬件地址。其他的全部主机都不理睬这个ARP请求分组。ARP响应分组的主要内容是代表：“个人IP地址是192.168.0.4,个人硬件地址是08-00-2B-00-EE-AA”【请注意：虽然ARP请求分组是广播发送的，但ARP响应分组是普通的单播，即从一个源地址发送到一个目的地址】
- 主机A收到主机B的ARP响应分组后，就在其ARP缓冲表中写入主机B的IP地址到硬件地址的映射

十一、利用ARP和ICMP解释PING命令

Ping会判断发送的是主机名仍是IP地址
- 若是是主机名：【DNS域名解析】调用gethostbyname()解析主机B，将主机名转换成一个32位的IP地址
Ping向目的IP发送一个ICMP的echo包
将目的IP地址转换为48位硬件地址：【ARP协议】在局域网中发送ARP请求分组【广播】
主机B收到ARP的请求分组后，将本机硬件地址填充到应答包，发送ARP响应分组给主机A【单播】
主机A发送ICMP数据包给主机B
主机B收到主机A的ICMP包以后，发送ICMP响应包
主机A接收到主机B的ICMP响应包

## 参考文章：http://www.javashuo.com/article/p-qauslegb-de.html

十二、浏览器怎么获得url地址？

　　URL：统一资源定位符，也就是网络资源的地址

【例子：你要去旅馆找一我的你必须知道他住在那个房间，这时候房间号就是你要找的人对应的地址，也就是这个场景下的URL。】

http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument

http://  　　　　 　　　　是协议

www.example.com  　　　　是域名，代表正在请求哪一个WEB服务器
：80　　　　　　　　　　　　是端口号

/path/to/myfile.html　　是网络服务器上资源的路径

key1=value1&key2=value2 是提供给网络服务器的额外参数

#SomewhereInTheDocument 是资源自己的另外一部分的锚点（书签）

URL解析：知道要访问的主机名，端口号以及请求资源的路径
DNS解析：从URL中解析出IP地址

## 参考文章：http://www.javashuo.com/article/p-yzjiyyfl-ep.html

1三、在浏览器中输入一串地址发生的过程

1四、DNS解析过程

1五、C/S模型的代码逻辑

1六、IP怎么寻址？

十二、OSI七层网络模型中每层的功能

OSI七层模型应用层表示层会话层传输层网络层数据链路层物理层

TCP/IP五层模型应用层传输层网络层数据链路层物理层

TCP/IP四层模型应用层传输层网络层网络接口层

应用层：为特定应用程序提供数据传输服务。（ TFTP，HTTP，SNMP，FTP，SMTP，DNS，Telnet）

表示层：对上层信息进行变换，保证一个主机应用层信息被另外一个主机的应用程序理解，表示层的数据转换包括数据的加密、压缩、格式转换。

会话层：管理主机之间的会话进程，即负责创建、管理、终止。

传输层：提供端对端的接口。（ TCP，UDP）

网络层：为数据包选择路由。（IP，ICMP，ARP,RARP）

数据链路层：传输有地址的帧，错误检测功能（ SLIP，CSLIP，PPP，ARP，RARP，MTU）

物理层：以二进制数据形式在物理媒体上传输数据。 ISO2110，IEEE802，IEEE802.2