面试题

转自朋友

知识点总结：
三次握手建立连接时，发送方再次发送确认的必要性？
主要是为了防止已失效的连接请求报文段突然又传到了B,因而产生错误。假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结 点长时间滞留了，一直延迟到连接释放以后的某个时间才到达B，本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误认为是A又发出一次 新的连接请求，于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了，这样一直等待A发来数据，B的许多 资源就这样白白浪费了。

四次挥手释放连接时，等待2MSL的意义？
1，为了保证A发送的最有一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN和ACK 报文段的确认。B会超时重传这个FIN和ACK报文段，而A就能在2MSL时间内收到这个重传的ACK+FIN报文段。接着A重传一次确认。
2，就是防止上面提到的已失效的连接请求报文段出现在本连接中，A在发送完最有一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。

TCP协议和UDP协议的区别是什么
TCP协议是有连接的，有连接的意思是开始传输实际数据之前TCP的客户端和服务器端必须通过三次握手建立连接，会话结束之后也要结束连接。而UDP是无连接的
TCP协议保证数据按序发送，按序到达，提供超时重传来保证可靠性，但是UDP不保证按序到达，甚至不保证到达，只是努力交付，即便是按序发送的序列，也不保证按序送到。
TCP协议所需资源多，TCP首部需20个字节（不算可选项），UDP首部字段只需8个字节。
TCP有流量控制和拥塞控制，UDP没有，网络拥堵不会影响发送端的发送速率
TCP是一对一的连接，而UDP则可以支持一对一，多对多，一对多的通信。
TCP面向的是字节流的服务，UDP面向的是报文的服务。

为什么建立连接是三次握手，而关闭连接却是四次挥手呢？
这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

TCP三次握手过程
第一次握手：建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认；
SYN：同步序列编号(Synchronize Sequence Numbers)
第二次握手：服务器收到syn包,必须确认客户的SYN（ack=j+1）,同时自己也发送一个SYN包（syn=k）,即SYN+ACK包,此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手.

TCP四次挥手过程
1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

僵尸进程产生的原因
如果子进程先于父进程退出， 同时父进程又没有调用wait/waitpid，则该子进程将成为僵尸进程。

如何避免产生僵尸进程？
1.一般，为了防止产生僵尸进程，在fork子进程之后我们都要wait它们；
2.同时，当子进程退出的时候，内核都会给父进程一个SIGCHLD信号，所以我们可以建立一个捕获SIGCHLD信号的信号处理函数，在函数体中调用wait（或waitpid），就可以清理退出的子进程以达到防止僵尸进程的目的；
3.如果父进程不关心重点内容子进程什么时候结束，那么可以用signal（SIGCLD, SIG_IGN）或signal（SIGCHLD, SIG_IGN）通知内核，自己对子进程的结束不感兴趣，那么子进程结束后，内核会回收，并不再给父进程发送信号；

进程间的通信（(IPC，Inter-Process Communication）方式：
IPC的方式通常有管道(包括无名管道和命名管道)、消息队列、信号量、共享存储、Socket、Streams等。其中 Socket和Streams支持不同主机上的两个进程IPC。
管道（pipe）：
半双工(数据流向仅有一个方向)，具有固定的读端和写端
只能用于父进程或兄弟线程之间通信(具有血缘关系的线程之间)
一种特殊文件，可以用普通的read、write函数进行读写，但又不是普通文件，不属于任何其它文件系统，仅存在于内存之中
命名管道（FIFO）：
FIFO，也称为命名管道，它是一种文件类型。与无名管道不同，命名管道可以在无关进程间通信；
FIFO以一种特殊设备文件形式存在于文件系统中，有路径名与之关联
消息队列：
消息队列，是消息的链接表，存放在内核中。一个消息队列由一个标识符(即队列ID)来标识。消息队列克服了信号传递信息少、管道只能承载无格式字节流以及缓冲区大小受限等缺点。
消息队列独立于发送与接收进程。进程终止时，消息队列及其内容并不会被删除（生命周期随内核）。
信号量：
信号量(semaphore)与已经介绍过的 IPC 结构不同，它是一个计数器。信号量用于实现进程间的互斥与同步，而不是用于存储进程间通信数据。
信号量用于进程间同步，若要在进程间传递数据需要结合共享内存
信号量基于操作系统的 PV 操作，程序对信号量的操作都是原子操作
每次对信号量的 PV 操作不仅限于对信号量值加 1 或减 1，而且可以加减任意正整数
支持信号量组
共享内存：
共享内存是最快的一种 IPC，因为进程是直接对内存进行存取；（创建共享内存：在物理内存上开辟空间；进程将共享内存映射到自己的虚拟地址空间；）
信号量+共享内存通常结合在一起使用，信号量用来同步对共享内存的访问；
Socket：
套解字也是一种进程间通信机制，与其他通信机制不同的是，它可用于不同机器间的进程通信

epool与select的区别：
问题的引出，当需要读两个以上的I/O的时候，如果使用阻塞式的I/O，那么可能长时间的阻塞在一个描述符上面，另外的描述符虽然有数据但是不能读出来，这样实时性不能满足要求，大概的解决方案有以下几种：
1.使用多进程或者多线程，但是这种方法会造成程序的复杂，而且对与进程与线程的创建维护也需要很多的开销。（Apache服务器是用的子进程的方式，优点可以隔离用户）
2.用一个进程，但是使用非阻塞的I/O读取数据，当一个I/O不可读的时候立刻返回，检查下一个是否可读，这种形式的循环为轮询（polling），这种方法比较浪费CPU时间，因为大多数时间是不可读，但是仍花费时间不断反复执行read系统调用。
3.异步I/O（asynchronous I/O），当一个描述符准备好的时候用一个信号告诉进程，但是由于信号个数有限，多个描述符时不适用。
4.一种较好的方式为I/O多路转接（I/O multiplexing）（貌似也翻译多路复用），先构造一张有关描述符的列表（epoll中为队列），然后调用一个函数，直到这些描述符中的一个准备好时才返回，返回时告诉进程哪些I/O就绪。select和epoll这两个机制都是多路I/O机制的解决方案，select为POSIX标准中的，而epoll为Linux所特有的。

区别（epoll相对select优点）主要有三：
1.select的句柄数目受限，在linux/posix_types.h头文件有这样的声明：#define __FD_SETSIZE 1024 表示select最多同时监听1024个fd。而epoll没有，它的限制是最大的打开文件句柄数目。
2.epoll的最大好处是不会随着FD的数目增长而降低效率，在selec中采用轮询处理，其中的数据结构类似一个数组的数据结构，而epoll是维护一个队列，直接看队列是不是空就可以了。epoll只会对"活跃"的socket进行操作—这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有"活跃"的socket才会主动的去调用 callback函数（把这个句柄加入队列），其他idle状态句柄则不会，在这点上，epoll实现了一个"伪"AIO。但是如果绝大部分的I/O都是“活跃的”，每个I/O端口使用率很高的话，epoll效率不一定比select高（可能是要维护队列复杂）。
3.使用mmap加速内核与用户空间的消息传递。无论是select,poll还是epoll都需要内核把FD消息通知给用户空间，如何避免不必要的内存拷贝就很重要，在这点上，epoll是通过内核于用户空间mmap同一块内存实现的。

epool中et和lt的区别与实现原理：
epoll有2种工作方式:LT和ET。
LT(level triggered)是缺省的工作方式，并且同时支持block和no-block socket.在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你 的，所以，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表．
ET (edge-triggered)是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述 符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致 了一个EWOULDBLOCK 错误）。但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once),不过在TCP协议中，ET模式的加速效用仍需要更多的benchmark确认。
epoll只有epoll_create,epoll_ctl,epoll_wait 3个系统调用。

流量控制和拥塞控制的实现机制：
1）TCP采用大小可变的滑动窗口机制实现流量控制功能。窗口的大小是字节。在TCP报文段首部的窗口字段写入的数值就是当前给对方设置发送窗口的数据的上限。在数据传输过程中，TCP提供了一种基于滑动窗口协议的流量控制机制，用接收端接收能力（缓冲区的容量）的大小来控制发送端发送的数据量。
2）采用滑动窗口机制还可对网络进行拥塞控制，将网络中的分组（TCP报文段作为其数据部分）数量维持在一定的数量之下，当超过该数值时，网络的性能会急剧恶化。传输层的拥塞控制有慢开始（Slow-Start）、拥塞避免（Congestion Avoidance）、快重传（Fast Retransmit）和快恢复（Fast Recovery）四种算法。
拥塞：　大量数据报涌入同一交换节点（如路由器），导致该节点资源耗尽而必须丢弃后面到达的数据报时，就是拥塞。

进程和线程的区别：
线程是指进程内的一个执行单元,也是进程内的可调度实体。与进程的区别:
(1)调度：线程作为调度和分配的基本单位，进程作为拥有资源的基本单位。
(2)并发性：不仅进程之间可以并发执行，同一个进程的多个线程之间也可并发执行。
(3)拥有资源：进程是拥有资源的一个独立单位，线程不拥有系统资源，但可以访问隶属于进程的资源.
(4)系统开销：在创建或撤消进程时，由于系统都要为之分配和回收资源，导致系统的开销明显大于创建或撤消线程时的开销。

TLS握手过程：
客户端与服务器在通过TLS交换数据之前，必须协商建立加密信道。协商内容包括：TLS版本、加密套件，必要时还要验证证书。其每次协商，都需要在客户端和服务端往返，大致过程如下：
1. TLS运行在TCP基础之上，这意味着我们必须首先完成TCP 三次握手“ ，这需要一个完整的来回交互(RTT)。
2. TCP连接建立后，客户端发送一些协商信息，如TLS协议版本，支持的密码套件的列表，和其他TLS选项。
3.服务器挑选TLS协议版本，在加密套件列表中挑选一个密码套件，附带自己的证书，并将响应返回给客户端。可选的，服务器也可以发送对客户端的证书认证请求和其他TLS扩展参数。
4.假设双方协商好一个共同的TLS版本和加密算法，客户端使用服务器提供的证书，生成新的对称密钥，并用服务器的公钥进行加密，并告诉服务器切换到加密通信流程。到现在为止，所有被交换的数据都是以明文方式传输，除了对称密钥外，它采用的是服务器端的公钥加密。
5.服务器用自己的私钥解密客户端发过来的对称密钥，并通过验证MAC检查消息的完整性，并返回给客户端一个加密的“Finished”的消息。（相互验证消息内容：Change Cipher Spec / Finished）
6.客户端采用对称密钥解密消息，并验证MAC，如果一切OK，加密隧道就建立好了。应用程序数据就可以发送了。

浏览器输入URL按回车背后的经历：
域名解析 --> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求，浏览器得到html代码 --> 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等） --> 浏览器对页面进行渲染呈现给用户

HTTPS和HTTP的区别主要如下：
　　1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
　　2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
　　3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
　　4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

GET和POST的区别：
对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。