计算机网络面试问题总结

I/O复用

12.五种IO复用

参考>>

13.Reactor和Proactor

参考>>

Reactor模型

mainReactor负责监听server socket，用来处理新连接的建立，将建立的socketChannel指定注册给subReactor。
subReactor维护自己的selector, 基于mainReactor 注册的socketChannel多路分离IO读写事件，读写网 络数据，对业务处理的功能，另其扔给worker线程池来完成。
我们可以看到，mainReactor 主要是用来处理网络IO 连接建立操作，通常一个线程就可以处理，而subReactor主要做和建立起来的socket做数据交互和事件业务处理操作，它的个数上一般是和CPU个数等同，每个subReactor一个县城来处理。
[参考文章>>>>>>>>>>>>>>>>>>>>>>>>]
两者的区别：
在Reactor模式中，事件分离者等待某个事件或者可应用或个操作的状态发生（比如文件描述符可读写，或者是socket可读写），事件分离器就把这个事件传给事先注册的处理器（事件处理函数或者回调函数），由后者来做实际的读写操作。
在Proactor模式中，事件处理者(或者代由事件分离者发起)直接发起一个异步读写操作(相当于请求)，而实际的工作是由操作系统来完成的。发起时，需要提供的参数包括用于存放读到数据的缓存区，读的数据大小，或者用于存放外发数据的缓存区，以及这个请求完后的回调函数等信息。事件分离者得知了这个请求，它默默等待这个请求的完成，然后转发完成事件给相应的事件处理者或者回调。
可以看出两者的区别：Reactor是在事件发生时就通知事先注册的事件（读写由处理函数完成）；Proactor是在事件发生时进行异步I/O（读写由OS完成），待IO完成事件分离器才调度处理器来处理。

14.epoll如何判断数据已经读取完成

=====>
只有在使用epoll ET(Edge Trigger)模式的时候，才需要关注数据是否读取完毕了。使用select或者epoll的LT模式，其实根本不用关注数据是否读完了，select/epoll检测到有数据可读去读就OK了。
两种做法：
1、针对TCP，调用recv方法，根据recv的返回值。如果返回值小于我们设定的recv buff的大小，那么就认为接收完毕。
2、TCP、UDP都适用，将socket设为NOBLOCK状态（使用fcntl函数），然后select该socket可读的时候，使用read/recv函数读取数据。当返回值为-1，并且errno是EAGAIN或EWOULDBLOCK的时候，表示数据读取完毕。

1.select poll 和epoll的原理以及最大区别

参考文章>>
select原理：，需要一个fd_set 集合来记录每个连接的文件描述符，该集合使用位图的方式，每一位都表示一个文件描述符，1表示已连接，0表示为连接，将fd_set 拷贝一份后传入内核，由内核对fd_set 内进行轮询检测，将fd_set 中已连接但未就绪的文件描述符置为0，返回文件描述符集合，然后在用户态中对fd_set 中的连接进行通信。用户态下还需要对fd_set集合进行轮询。
poll原理：也需要进行由用户态到内核态下数据的拷贝，与select不同，poll直接将要检测的文件描述符的信息封装到结构体struct pollfd中，用户态和内核态下都可直接读写结构体变量。结构体中存储着文件描述符，委托内核检测的事件，以及该文件描述符实际发生的事件。内核检测到事件后改写这个事件，如何没检测到任何事件，则将这个结构体的文件描述符置为-1。
epoll原理：首先通过epoll_create()。同时会创建一个event_poll结构体，结构体中存储着一颗红黑树的根节点，每次有连接，通过epoll_ctrl()函数就会将连接的文件描述符放入红红黑树中，该红黑树一直维护在内核中，这是因为红黑树查找插入删除的效率都比较高。同时该结构体中还存储一个双向链表，当某个文件描述符有事件发生时，会调用自身的回调函数，将该节点的信息存储在链表中，该链表存储着已经准备就绪的文件描述符信息。当用户态下调用epoll_wait()函数时，内核直接检测该双向链表中是否有元素存在，有元素就将发生的事件拷贝到用户态。
epoll会为每个连接创建一个epoll_event结构体

struct epoll_event {
	uint32_t     events;      /* Epoll events */
	epoll_data_t data;        /* User data variable */
};

epoll_event中有一个联合体，通常用该联合体的int类型的fd，还有一个数据表示事件类型，调用epoll_wait后，内核会帮助检测每个连接的是否就绪，是否就绪事件是被用户委托检测的事件，然后将合适的连接同样保存到epoll_event evs结构体数组中，供用户态使用。

struct eventpoll{
    ....
    /*红黑树的根节点，这颗树中存储着所有添加到epoll中的需要监控的事件*/
    struct rb_root  rbr;
    /*双链表中则存放着将要通过epoll_wait返回给用户的满足条件的事件*/
    struct list_head rdlist;
    ....
};

区别：

• 1.是否跨平台：
  select可以跨平台，poll和epoll不可以
• 2.是否有最大连接数限制
  select最大1024，poll和epoll没有
• 3.如何查询描述符状态
  select和poll采用遍历轮询，epoll不轮询，采用回调机制，事件驱动。
• 4.是否在用户态和内核态之间拷贝检测集合
  select和poll每次调用都会拷贝文件描述符集合，epoll中每个文件描述符只在注册时拷贝一次。注：select往内核拷贝检测集合的副本，poll往内核拷贝检测集合原集合。
  最大区别：
  1.查询文件描述符的状态，select和poll采用轮询；epoll采用回调机制，是事件驱动的，就绪的设备会自动将文件描述符添加到就绪链表中。
  2.select/poll 低效的原因之一是将 “添加 / 维护待检测任务” 和 “阻塞进程 / 线程” 两个步骤合二为一。每次调用 select 都需要这两步操作，然而大多数应用场景中，需要监视的 socket 个数相对固定，并不需要每次都修改。epoll 将这两个操作分开，先用 epoll_ctl() 维护等待队列，再调用 epoll_wait() 阻塞进程（解耦）。
  参考文章>>

形象的参考文章>>

2.什么是IO复用

形象参考文章>>
概念1 ：什么是文件
实际上所有的I/O设备都被抽象为了文件这个概念，一切皆文件，Everything is File，磁盘、网络数据、终端，甚至进程间通信工具管道pipe等都被当做文件对待。
概念2：什么是文件描述符
在Linux世界要想使用文件，我们也需要借助一个号码，这个号码就、被称为了文件描述符，file descriptors。文件描述仅仅就是一个数字而已，但是通过这个数字我们可以操作一个打开的文件。
有了文件描述符，进程可以对文件一无所知，比如文件在磁盘的什么位置、加载到内存中又是怎样管理的等等，这些信息统统交由操作系统打理，进程无需关心，操作系统只需要给进程一个文件描述符就足够了。
关于IO复用：
在网络编程中，当连接个数比较少时，借助accept即可获得一个文件描述符，但是当出现大量连接时，我们不能每次只获取一个连接然后进行通信，需要将已就绪的文件描述符全部获取然后通信，这时候就需要IO复用，即一次可以处理多路IO。
I/O多路复用，I/O multiplexing，multiplexing一词其实多用于通信领域，为了充分利用通信线路，希望在一个信道中传输多路信号，要想在一个信道中传输多路信号就需要把这多路信号结合为一路，将多路信号组合成一个信号的设备被称为multiplexer，显然接收方接收到这一路组合后的信号后要恢复原先的多路信号，这个设备被称为demultiplexer，如图所示：

所以I/O多路复用指的是这样一个过程：

1. 我们拿到了一堆文件描述符(不管是网络相关的、还是磁盘文件相关等等，任何文件描述符都可以)
2. 通过调用某个函数告诉内核：“替我监视着这些描述符，当这堆文件描述符中有可以进行I/O读写操作的时候你再返回”
3. 当调用的这个函数返回后我们就能知道哪些文件描述符可以进行I/O操作了。

通俗：IO 多路转接的意思是在一个操作里同时监听多个输入输出源，在其中一个或多个输入输出源可用的时候返回，然后对其的进行读写操作。
三大IO复用机制：

select
poll
epoll

3.阻塞 I/O 和非阻塞 I/O,具体是怎么样的

1.阻塞I/O

进程发起IO系统调用后，进程被阻塞，转到内核空间处理，整个IO处理完毕后返回进程。操作成功则进程获取到数据。
典型应用：
阻塞socket
特点：

• 进程阻塞挂起不消耗CPU资源，及时响应每个操作；

• 实现难度低、开发应用较容易；

• 适用并发量小的网络应用开发；

• 不适用并发量大的应用：因为一个请求IO会阻塞进程（线程），所以，得为每请求分配一个处理进程（线程）以及时响应，系统开销大。

2.非阻塞IO模型

• 
  进程发起IO系统调用后，如果内核缓冲区没有数据，需要到IO设备中读取，进程返回一个错误而不会被阻塞；进程发起IO系统调用后，如果内核缓冲区有数据，内核就会把数据返回进程。
  对于上面的阻塞IO模型来说，内核数据没准备好需要进程阻塞的时候，就返回一个错误，以使得进程不被阻塞。

典型应用：
socket是非阻塞的方式（设置为NONBLOCK）

特点：

• 进程轮询（重复）调用，消耗CPU的资源；

• 实现难度低、开发应用相对阻塞IO模式较难；

• 适用并发量较小、且不需要及时响应的网络应用开发；

5.epoll为什么ctrl和wait分开

参考文章>>
select/poll 低效的原因之一是将 “添加 / 维护待检测任务” 和 “阻塞进程 / 线程” 两个步骤合二为一。每次调用 select 都需要这两步操作，然而大多数应用场景中，需要监视的 socket 个数相对固定，并不需要每次都修改。epoll 将这两个操作分开，先用 epoll_ctl() 维护等待队列，再调用 epoll_wait() 阻塞进程（解耦）。

6.公网和私网IP如何转换

7.epoll反应堆模型

参考文章>>
1.传统的epoll服务器模型
监听可读事件(ET) ⇒ 数据到来⇒ 触发读事件 ⇒epoll_wait()返回 ⇒read消息 ⇒ write回射信息 ⇒ 继续epoll_wait()⇒ 直到程序停止前都是这么循环。

2.epoll反应堆服务器模型
监听可读事件(ET) ⇒ 数据到来 ⇒ 触发读事件⇒epoll_wait()返回 ⇒read完数据; 节点下树; 设置监听写事件和对应写回调函数; 节点上树(可读事件回调函数内)⇒ 监听可写事件(ET) ⇒ 对方可读 ⇒ 触发事件 ⇒epoll_wait()返回 ⇒write数据; 节点下树; 设置监听读事件和对应可读回调函数; 节点上树(可写事件回调函数内)⇒ 直到程序停止前一直这么交替循环。

原因：
为什么要可读以后设置可写？然后一直交替？
服务器向客户端write数据，并不一定能write成功，原因有二
(1) 滑动窗口机制：
服务器向客户端write数据，假设刚好此时客户端的接收滑动窗口满，将导致当前服务器将阻塞在send函数处，导致服务器程序阻塞。
解决方案：设置可写事件，当客户端的接收缓冲区有空闲时，将导致该socket可写，在可写回调函数中调用send函数
(2) SIGPIPE信号：
客户端send完数据后，突然由于异常停止，这将导致一个FIN发送给服务器。如果服务器不设置可写事件监听，那么服务器在read完数据后，直接向没有读端的套接字中写入数据，TCP协议栈将会给服务器发送RST分节+SIGPIPE信号，导致服务器进程终止。

8.ping命令的原理

简单来说，「ping」是用来探测本机与网络中另一主机之间是否可达的命令，如果两台主机之间ping不通，则表明这两台主机不能建立起连接。ping是定位网络通不通的一个重要手段。
ping 命令是基于 ICMP 协议来工作的，「 ICMP 」全称为 Internet 控制报文协议（ Internet Control Message Protocol）。ping 命令会发送一份ICMP回显请求报文给目标主机，并等待目标主机返回ICMP回显应答。因为ICMP协议会要求目标主机在收到消息之后，必须返回ICMP应答消息给源主机，如果源主机在一定时间内收到了目标主机的应答，则表明两台主机之间网络是可达的。

9.socket的阻塞模式与非阻塞模式

参考文章>>

Windows套接字在阻塞和非阻塞两种模式下执行I/O操作。在阻塞模式下，在I/O操作完成前，执行的操作函数一直等候而不会立即返回，该函数所在的线程会阻塞在这里。相反，在非阻塞模式下，套接字函数会立即返回，而不管I/O是否完成，该函数所在的线程会继续运行。
阻塞模式下：
bind()、listen()函数时，函数会立即返回。
recv()、recvfrom()、WSARecv()和WSARecvfrom()函数。以阻塞套接字为参数调用该函数接收数据。如果此时套接字缓冲区内没有数据可读，则调用线程在数据到来前一直睡眠。
send()、sendto()、WSASend()和WSASendto()函数。以阻塞套接字为参数调用该函数发送数据。如果套接字缓冲区没有可用空间，线程会一直睡眠，直到有空间。
accept()和WSAAcept()函数。以阻塞套接字为参数调用该函数，等待接受对方的连接请求。如果此时没有连接请求，线程就会进入睡眠状态。
connect()和WSAConnect()函数。对于TCP连接，客户端以阻塞套接字为参数，调用该函数向服务器发起连接。该函数在收到服务器的应答前，不会返回。这意味着TCP连接总会等待至少到服务器的一次往返时间。
非阻塞模式下：
套接字设置为非阻塞模式后，在调用API函数时，调用函数会立即返回。大多数情况下，这些函数调用都会调用“失败”，并返回错误代码，bind()函数时不会返回错误代码。

10.ET模式与LT模式

参考文章>>
LT 和 ET本质的区别是：
LT模式状态时，主线程正在epoll_wait等待事件时，请求到了，epoll_wait返回后没有去处理请求(recv)，那么下次epoll_wait时此请求还是会返回（立刻返回了）；而ET模式状态下，这次没处理，下次epoll_wait时将不返回（所以我们应该每次一定要处理），可见很大程度降低了epoll的触发次数（记住这句话先）。

11.htonl函数

====>>>>

将小端存储模式转换为大端存储模式：
大端（存储）模式，是指数据的低位保存在内存的高地址中，而数据的高位保存在内存的低地址中
小端（存储）模式，是指数据的低位保存在内存的低地址中，而数据的高位保存在内存的高地址中
大端（存储）模式，是指数据的低位保存在内存的高地址中，而数据的高位保存在内存的低地址中
小端（存储）模式，是指数据的低位保存在内存的低地址中，而数据的高位保存在内存的高地址中
存在原因：
每个地址单元都是以字节为单位，即8位，当所需存储的数据大于1字节时，就存在一个存储顺序的问题，因此就有了大小端的问题。
计算机内小端字节序：计算机电路先处理低位字节，效率比较高，因为计算都是从低位开始的，所以，计算机的内部处理都是小端字节序。
外部使用大端字节序：人类还是习惯读写大端字节序，所以，除了计算机的内部处理，其他的场合几乎都是大端字节序，比如网络传输和文件储存。

总结：大端模式就是数据从高字节到低字节在内存中排列，小端模式就是数据从低字节到高字节在内存中排列，数据本身字节是高字节在左，低字节在右。（如二进制8421）。
大小端检测方法：
原理：由于数据对齐的原因，地址的增长方向是由小变大，c是1字节，i是四字节，联合体公用一块内存。在这里就是共用4字节的内存。c放在最开始的第一个字节，如果数据时小端存储，则1应该在c的位置，如果是大端存储，则c的位置上放的是0。

#include 
#include 
int check()
{
    union UN
    {
        char c;
        int i;
    }un;
    un.i = 1;
    return un.c;
}

int main(void)
{
    if(check()==1)
        printf("小端模式存储！\n");
    else
        printf("大端模式存储！\n");
    return 0;
}

htonl、ntohl、htons、ntohs函数实现

TCP/IP协议

4.键入www.baidu.com后发生的全过程

参考文章>>
参考文章>>

1.DNS将域名解析为IP地址：DNS解析过程
2.浏览器与目标服务器建立TCP连接：三次握手过程，第三次握手时发送请求
3.浏览器通过http协议发送请求
4.服务器处理请求
5.服务器发出一个HTML响应
6.释放TCP连接
7.浏览器显示页面

5.2MSL

参考文章>>
原因一：客户端进行第四次挥手ACK后，启动2MSL计时，ACK+seq+ack最多在1MSL就能到达服务端，如果在1MSL没到达服务端，服务端会再次重传FIN+seq+ack+ACK，到达客户端最多耗时1MSL，客户端收到重传的FIN，会再次发送ACK，并启动2MSL计时器。
原因二：如果不等待这个2MSL而是立即关闭，服务端端口自由，与新的客户端发生了新的连接，如果服务端没有收到上个客户端的第四次挥手的ACK,或者由于网络中的路由器重复发送FIN报文，会导致刚产生的新连接被关闭，产生误关闭；或者FIN并没被重发，而是重复发了其他数据，会导致新连接数据错乱。所有2MSL可以使本次连接持续的时间内所产生的所有报文段都从网络中消失。

6.TCP三次握手四次挥手流程

三次握手四次挥手问题汇总：参考文章>>

1.三次握手建立连接流程

三次握手流程：
（1）第一次握手：建立连接时，客户端A发送SYN包（seq=j，SYN标志位=1）到服务器B，并进入SYN_SEND状态，等待服务器B确认。

（2）第二次握手：服务器B收到SYN包，必须确认客户A的SYN（ack=j+1及ACK应答），同时自己也发送一个SYN包（seq=k，SYN标志位 = 1），即SYN+ACK包，此时服务器B进入SYN_RECV状态。

（3）第三次握手：客户端A收到服务器B的SYN＋ACK包，向服务器B发送确认包ACK（seq= j+1,ack=k+1,ACK 应答），此包发送完毕，客户端A和服务器B进入ESTABLISHED状态，完成三次握手。

2.四次挥手流程

流程：
（1）第一次挥手：客户端主动发送FIN释放连接请求、seq = u序号到服务器，请求停止发送数据，进入FIN_WAIT_1（终止等待1），处于一种半关闭状态。
（2）第二次挥手：服务端发送ACK应答及ack =u+1 ，以及seq = v，B进入CLOS_WAIT(等待关闭)，客户端到服务端这个方向的连接就关闭了。但客户端还可以接收。客户端收到来自服务端的确认ACK，进入FIN_WAIT_2（终止等待2），等待服务端发送释放连接报文。
（3）服务端发送FIN释放连接请求，ACK应答，seq = w（中间又有数据传输），ack= u+1,服务端进入LAST_ACK（最后确认状态）。
（4）客户端发送ACK应答，seq=u+1,ack=w+1到服务端，进入FIN_WAIT(最终等待)，等待2MSL后关闭。

客户端：主动连接，主动关闭：
主动发起连接请求—>另一端响应请求————>建立连接状态————>传输数据—————>发起关闭请求————>半连接状态——>另一端响应请求—>另一端发起关闭请求————>本端响应请求———>等待2MSL————>关闭状态。
服务端：被动连接，被动关闭：
被动接受连接请求————>建立连接状态————>传输数据————>被动接受关闭请求————>等待关闭状态（等待剩余数据发送完成）————>发起关闭请求————>接收到对方ACK——>关闭。

7.TCP十种状态

LISTEN - 侦听来自远方TCP端口的连接请求； 
SYN-SENT -在发送连接请求后等待匹配的连接请求； 
SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认； 
ESTABLISHED- 代表一个打开的连接，数据可以传送给用户； 
FIN-WAIT-1 - 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；
FIN-WAIT-2 - 从远程TCP等待连接中断请求； 
CLOSE-WAIT - 等待从本地用户发来的连接中断请求； 
CLOSING -等待远程TCP对连接中断的确认； 
LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认； 
TIME-WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认； 
CLOSED - 没有任何连接状态；

8.TCP各个标志位的意义

位码即tcp标志位,有6种标示:

1.SYN(synchronous建立联机)

2.ACK(acknowledgement 确认)

3.PSH(push传送)

4.FIN(finish结束)

5.RST(reset重置)

6.URG(urgent紧急)

需要发送的号码：
Sequence number(顺序号码)

Acknowledge number(确认号码)

9.三次握手必要性

参考文章>>
确保能成功连接
1.假如一次握手
首先tcp是面向连接，一次握手肯定建立不了连接，因为客户机给服务器发出请求信息却没有得到回应，客户机是没法判定是否发送成功然后建立连接的。
2.假如两次握手
假设只有两次握手，比如图中的1，2步，当A想要建立连接时发送一个SYN，然后等待ACK，结果这个SYN因为网络问题没有及时到达B，所以A在一段时间内没收到ACK后，再发送第二个SYN，这次B顺利收到第二个请求，接着A也收到B发送来的ACK，这时A发送的第一个SYN经过一段时间也到了B，对于B来说这是一个新连接请求，然后B又为这个连接申请资源，返回ACK，然而这个SYN是个无效的请求，A只会承认它最后发的那个SYN的SYN+ACK，A收到B发来的第二个ACK实际是回应A的第一个SYN，所以A并不会理会它，而B却不知道，B会一直为这个连接维持着资源，造成资源的浪费。
3.假如三次握手
两次握手的问题在于服务器端不知道一个SYN是否是无效的，而三次握手机制因为客户端会给服务器回复第二次握手，也意味着服务器会等待客户端的第三次握手，与两次握手不同的是，服务器可以通过第三次握手来确认第一个连接请求是否有效，如果第三次握手迟迟不来，服务器便会认为这个SYN是无效的，释放相关资源。但这时有个问题就是客户端完成第二次握手便认为连接已建立，而第三次握手可能在传输中丢失，服务端会认为连接是无效的，这时如果Client端向Server写数据，Server端将以RST包响应，这时便感知到发生了错误。

10.三次握手出错的处理方法

1. 第一次握手A发送SYN传输失败，A,B都不会申请资源，连接失败。如果一段时间内发出多个SYN连接请求，那么A只会接受并回应第一个收到的SYN+ACK，忽略其他回应全部回应，B中多申请的资源也会释放。
2. 第二次握手B发送SYN+ACK传输失败，A不会申请资源，B申请了资源，但收不到A的ACK，过一段时间释放资源。如果是收到了多个A的SYN请求，B都会回复SYN+ACK，但A只会进行一次连接。
3. 第三次握手ACK传输失败，B没有收到ACK，释放资源，对于后序的A的传输数据返回RST。实际上B会因为没有收到A的ACK会多次发送SYN+ACK，次数是可以设置的，如果最后还是没有收到A的ACK，则释放资源，对A的数据传输返回RST。

11.四次挥手必要性

这是因为TCP半关闭造成的。由于一个TCP连接是全双工的，在两个方向上都能传输数据，因此两个方向就需要单独关闭。
参考文章>>

12.TCP长连接，短连接

长连接：在基于tcp的通讯中，一直保持连接，不管当前是否发送或者接收数据。多用于操作频繁，点对点的通讯，而且连接数不能太多的情况。
短连接：在有数据传输的时候才进行连接，客户－服务器通信/传输数据完毕就关闭连接。
web网站的http服务一般都用短连接。
参考文章>>

在HTTP/1.0中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。

但从 HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头有加入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接要客户端和服务端都支持长连接。

== HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接== 。

什么时候长连接，什么时候短连接：
对于操作比较频繁的，连接数不多的情况下，使用长连接，可以对连接进行复用，节省资源。
对于操作不是很频繁情况下，连接数目比较多的情况下，使用短连接会比较好，因为服务器的可用连接数目是有限的，如果在这种情况下每个用户都占用一个连接的话，服务区早晚会撑不住。

13.TCP如何重连接

14.TCP如何保证可靠传输

参考文章>>
TCP通过七种方式保证可靠传输：

• 1.数据校验和：接收方对报文经计算后得到的校验和与发送方发送的校验和做对比，错误则说明传输一定有误，但是正确不一定能保证发送成功。
• 2.确认应答：接收方每次成功接收到数据后，会发送一个ACK应答，告诉发送方这段数据接收成功。
• 3.序列号：TCP每次传输都对数据进行了编号，这就是序列号，TCP传输的过称中，每次接收到数据后，都会对传输方进行ACK确认应答，应答报文中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里开始发。序列号还有去重复的功能。
• 4.超时重传：如果发送方发送的数据由于网络原因未到接收方，发送方等待一段时间还未接受到ACK应答则重新发送数据；如果发送方发送的数据已经被接收方接收到，但接收方发送的ACK应答丢包，则发送方还是会多次发送数据，接收方终有一次接收到了数据，根据序列号判断接收的数据已经存在，也直接丢弃报文，并发送ACK应答报文。
  超时重传的时间：太短会导致报文频繁重发，太长则导致TCP效率下降。
  方法：对于同一个报文，取一个固定时长如500ms，每重传一次等待时间指数倍增长，尝试指定次数还未接收到数据则关闭连接。
• 5.连接管理：即TCP三次握手四次挥手
• 6.流量控制：TCP根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制。接收端会在发送ACK应答报文的时候，将自己接收缓冲区的剩余大小一并发送给发送端，称为窗口大小，发送端根据这个数据大小来调整自己每次发送速度。如果接收方缓冲区为0，则发送方停止发送，并每隔一段时间发送窗口探测报文，获取接收方剩余缓存大小。
• 7.拥塞控制：为了保证在不知道网络拥堵程度的情况下，数据能够正确传输，不被丢包，TCP创建了慢启动机制，即在刚建立连接后发送方的发送速度由慢变快。避免一建立连接就发送大量数据，如果网络不好则会导致大量数据重传，严重影响效率。同时引入了拥塞窗口的概念，设有阈值，拥塞窗口由1开始以指定速度增加，，遇到超时重传则回到1，并且改变阈值。每次取接收方发来的窗口大小与拥塞窗口的较小的那个作为发送数据的大小，拥塞控制是TCP在传输时尽可能快的将数据传输，并且避免拥塞造成的一系列问题。是可靠性的保证，同时也是维护了传输的高效性。

拥塞控制具体动作：

参考文章>>
1.慢开始：
假设当前发送方拥塞窗口cwnd的值为1，而发送窗口swnd等于拥塞窗口cwnd，因此发送方当前只能发送一个数据报文段（拥塞窗口cwnd的值是几，就能发送几个数据报文段），接收方收到该数据报文段后，给发送方回复一个确认报文段，发送方收到该确认报文后，将拥塞窗口的值变为2。慢开始的窗口值以指数方式增长。当前的拥塞窗口cwnd的值已经等于慢开始门限值，之后改用拥塞避免算法。
2.拥塞避免：
也就是每个传输轮次，拥塞窗口cwnd只能线性加一，而不是像慢开始算法时，每个传输轮次，拥塞窗口cwnd按指数增长。当发生超时重传时，回到慢开始算法，窗口值恢复为1。
3.快重传：
快重传是指使发送方尽快进行重传，而不是等超时重传计时器超时再重传。
要求接收方不要等待自己需要发送数据时才进行捎带确认，而是要立即发送确认；
即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认，即通知发送方需要正确发送的报文序号；
发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是在规定时间内收不到对应确认信号，因为超时重传计时器超时再重传。
这样：对于个别丢失的报文段，发送方不会出现超时重传，也就不会误认为出现了拥塞而采用拥塞避免算法，而是使用快恢复算法。
4.快恢复：
发送方一旦收到3个重复确认，就知道只是丢失了个别报文段，执行快恢复算法。
发送方将慢开始门限和拥塞窗口的值设为当前窗口值的一半，即快恢复算法。

15.TCP为什么会有多个CLOSE_WAIT状态

参考文章>>
参考文章>>
客户端发送FIN+seq释放连接请求后，服务端发送ACK+ack+seq应答后进入CLOSE_WAIT状态，如果大量存在CLOSE_WAIT状态，说明服务端没有发送FIN+seq+ACK+ack,可能正在忙于读。
对于socket编程，有以下解决方案：
1.使用完socket调用close方法
2.read()读取到的长度为0时，立即close
3.read返回-1，检查error返回码，如果不是AGAIN（现在没数据稍后重新读），则立即关闭
4.read设置超时，超时未读到数据则关闭。

16.TCP有大量TIME_WAIT的原因

• 高并发让服务器在短时间范围内同时占用大量端口，而端口只0~65535的范围，有限
• 短连接表示“业务处理+传输数据的时间 远远小于 TIMEWAIT超时的时间”的连接。

17.OSI七层协议及其作用

参考文章>>
参考文章>>
七层模型：

数据封装：不同的协议层对数据包有不同的称谓，在传输层叫做段（segment），在网络层叫做数据报（datagram），在链路层叫做帧（frame）加上MAC头，加完后再加上一个FCS校验组成数据帧，就封装完成了，然后在物理层通过Bit来传输。发到传输介质上，到达目的主机后每层协议再剥掉相应的首部，最后将应用层数据交给应用程序处理。

1.应用层：
直接向用户提供服务，完成用户希望在网络上完成的各种工作。
2.表示层：
表示层（Presentation Layer）是OSI模型的第六层，它对来自应用层的命令和数据进行解释，对各种语法赋予相应的含义，并按照一定的格式传送给会话层。其主要功能是“处理用户信息的表示问题，如编码、数据格式转换和加密解密”等。
3.会话层：
会话层的任务就是组织和协调两个会话进程之间的通信，并对数据交换进行管理。
主要任务：
会话管理：允许用户在两个实体设备之间建立、维持和终止会话，并支持它们之间的数据交换。例如提供单方向会话或双向同时会话，并管理会话中的发送顺序，以及会话所占用时间的长短。
会话流量控制：提供会话流量控制和交叉会话功能。
寻址：使用远程地址建立会话连接。
出错控制：从逻辑上讲会话层主要负责数据交换的建立、保持和终止，但实际的工作却是接收来自传输层的数据，并负责纠正错误。会话控制和远程过程调用均属于这一层的功能。但应注意，此层检查的错误不是通信介质的错误，而是磁盘空间、打印机缺纸等类型的高级错误。
4.传输层：
主要任务：
向用户提供可靠的端到端的差错和流量控制，保证报文的正确传输。
传输层的作用是向高层屏蔽下层数据通信的细节，即向用户透明地传送报文。该层常见的协议：TCP/IP中的TCP协议。
传输连接管理：提供建立、维护和拆除传输连接的功能。传输层在网络层的基础上为高层提供“面向连接”和“面向无接连”的两种服务。
处理传输差错：提供可靠的“面向连接”和不太可靠的“面向无连接”的数据传输服务、差错控制和流量控制。在提供“面向连接”服务时，通过这一层传输的数据将由目标设备确认，如果在指定的时间内未收到确认信息，数据将被重发。
5.网络层：
主要任务：
数据链路层的数据在这一层被转换为数据包，然后通过路径选择、分段组合、顺序、进/出路由等控制，将信息从一个网络设备传送到另一个网络设备。
一般地，数据链路层是解决同一网络内节点之间的通信，而网络层主要解决不同子网间的通信。例如在广域网之间通信时，必然会遇到路由（即两节点间可能有多条路径）选择问题。

寻址：数据链路层中使用的物理地址（如MAC地址）仅解决网络内部的寻址问题。在不同子网之间通信时，为了识别和找到网络中的设备，每一子网中的设备都会被分配一个唯一的地址。由于各子网使用的物理技术可能不同，因此这个地址应当是逻辑地址（如IP地址），需要网络层来找到指定IP地址。
路由算法：当源节点和目的节点之间存在多条路径时，本层可以根据路由算法，通过网络为数据分组选择最佳路径，并将信息从最合适的路径由发送端传送到接收端。
连接服务：与数据链路层流量控制不同的是，前者控制的是网络相邻节点间的流量，后者控制的是从源节点到目的节点间的流量。其目的在于防止阻塞，并进行差错检测。
6.数据链路层：
主要任务：
负责建立和管理节点间的链路。该层的主要功能是：通过各种控制协议，将有差错的物理信道变为无差错的、能可靠传输数据帧的数据链路。在物理层提供的比特流的基础上，通过差错控制、流量控制方法，使有差错的物理线路变为无差错的数据链路，即提供可靠的通过物理介质传输数据的方法。
该层通常又被分为介质访问控制（MAC）和逻辑链路控制（LLC）两个子层。
MAC子层的主要任务是解决共享型网络中多用户对信道竞争的问题，完成网络介质的访问控制；
LLC子层的主要任务是建立和维护网络连接，执行差错校验、流量控制和链路控制。

具体工作：接收来自物理层的位流形式的数据，并封装成帧，传送到上一层；同样，也将来自上层的数据帧，拆装为位流形式的数据转发到物理层；并且，还负责处理接收端发回的确认帧的信息，以便提供可靠的数据传输。
7.物理层：
主要功能：
利用传输介质为数据链路层提供物理连接，实现比特流的透明传输。
物理层的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。使其上面的数据链路层不必考虑网络的具体传输介质是什么。“透明传送比特流”表示经实际电路传送后的比特流没有发生变化，对传送的比特流来说，这个电路好像是看不见的。

18.TCP/IP协议

参考文章>>

19.TCP/IP四层网络模型

参考文章>>
TCP/IP协议族是一个四层协议系统，自底而上分别是数据链路层、网络层、传输层和应用层。每一层完成不同的功能，且通过若干协议来实现，上层协议使用下层协议提供的服务。

1.应用层：
直接向用户提供服务，完成用户希望在网络上完成的各种工作。
2.传输层：
传输层为两台主机上的应用程序提供端到端（end to end）的通信。传输层只关心通信的起始端和目的端，而不在乎数据包的中转过程。
传输层协议：TCP协议、UDP协议。
TCP协议（Transmission Control Protocol，传输控制协议）为应用层提供可靠的、面向连接的和基于流（stream）的服务。TCP协议使用超时重传、数据确认等方式来确保数据包被正确地发送至目的端，因此TCP服务是可靠的。使用TCP协议通信的双方必须先建立TCP连接，并在内核中为该连接维持一些必要的数据结构，比如连接的状态、读写缓冲区，以及诸多定时器等。当通信结束时，双方必须关闭连接以释放这些内核数据。TCP服务是基于流的。基于流的数据没有边界（长度）限制，它源源不断地从通信的一端流入另一端。发送端可以逐个字节地向数据流中写入数据，接收端也可以逐个字节地将它们读出。
UDP协议（User Datagram Protocol，用户数据报协议）则与TCP协议完全相反，它为应用层提供不可靠、无连接和基于数据报的服务。“不可靠”意味着UDP协议无法保证数据从发送端正确地传送到目的端。如果数据在中途丢失，或者目的端通过数据校验发现数据错误而将其丢弃，则UDP协议只是单地通知应用程序发送失败。因此，使用UDP协议的应用程序通常要自己处理数据确认、超时重传等逻辑。UDP协议是无连接的，即通信双方不保持一个长久的联系，因此应用程序每次发送数据都要明确指定接收端的地址（IP地址等信息）。基于数据报的服务，是相对基于流的服务而言的。每个UDP数据报都有一个长度，接收端必须以该长度为最小单位将其所有内容一次性读出，否则数据将被截断。
3.网络层：
网络层实现数据包的选路和转发。主要负责从源地址到目的地址的最优路径选择。
网络层最核心的协议是IP协议（Internet Protocol，因特网协议）。IP协议根据数据包的目的IP地址来决定如何投递它。如果数据包不能直接发送给目标主机，那么IP协议就为它寻找一个合适的下一跳（next hop）路由器，并将数据包交付给该路由器来转发。多次重复这一过程，数据包最终到达目标主机，或者由于发送失败而被丢弃。可见，IP协议使用逐跳（hop by hop）的方式确定通信路径。
WAN（Wide Area Network，广域网）通常使用众多分级的路由器来连接分散的主机或LAN（Local Area Network，局域网），因此，通信的两台主机一般不是直接相连的，而是通过多个中间节点（路由器）连接的。网络层的任务就是选择这些中间节点，以确定两台主机之间的通信路径。同时，网络层对上层协议隐藏了网络拓扑连接的细节，使得在传输层和网络应用程序看来，通信的双方是直接相连的。
ICMP（Internet Control Message Protocol）Internet控制报文协议。它是TCP/IP协议簇的一个子协议，用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用
4.数据链路层：
数据链路层实现了网卡接口的网络驱动程序，以处理数据在物理媒介（比如以太网、令牌环等）上的传输。
数据链路层两个常用的协议是ARP协议（Address Resolve Protocol，地址解析协议）和RARP协议（ReverseAddress Resolve Protocol，逆地址解析协议）。它们实现了IP地址和机器物理地址（通常是MAC地址，以太网、令牌环和802.11无线网络都使用MAC地址）之间的相互转换。即通过IP地址找到路由器。

ARP协议：网络层使用IP地址寻址一台机器，而数据链路层使用物理地址寻址一台机器，因此网络层必须先将目标机器的IP地址转化成其物理地址，才能使用数据链路层提供的服务。

RARP协议：仅用于网络上的某些无盘工作站。因为缺乏存储设备，无盘工作站无法记住自己的IP地址，但它们可以利用网卡上的物理地址来向网络管理者（服务器或网络管理软件）查询自身的IP地址。运行RARP服务的网络管理者通常存有该网络上所有机器的物理地址到IP地址的映射。

21.TCP的沾包问题

参考文章1>>
参考文章2>>

粘包的原因：

• 产生TCP粘包和拆包问题的主要原因是，操作系统在发送TCP数据的时候，底层会有一个缓冲区，例如1024个字节大小，如果一次请求发送的数据量比较小，没达到缓冲区大小，TCP则会将多个请求合并为同一个请求进行发送，这就形成了粘包问题；

拆包原因：

• 如果一次请求发送的数据量比较大，超过了缓冲区大小，TCP就会将其拆分为多次发送，这就是拆包，也就是将一个大的包拆分为多个小包进行发送。

粘包和拆包的三种情况：

• A和B两个包都刚好满足TCP缓冲区的大小，或者说其等待时间已经达到TCP等待时长，从而还是使用两个独立的包进行发送；
• A和B两次请求间隔时间内较短，并且数据包较小，因而合并为同一个包发送给服务端；
• B包比较大，因而将其拆分为两个包B_1和B_2进行发送，而这里由于拆分后的B_2比较小，其又与A包合并在一起发送。

解决方案：

• 使用带消息头的协议、消息头存储消息开始标识及消息长度信息，服务端获取消息头的时候解析出消息长度，然后向后读取该长度的内容。
• 设置定长消息，服务端每次读取既定长度的内容作为一条完整消息。
• 设置消息边界，服务端从网络流中按消息编辑分离出消息内容

22.MTU

参考文章>>
MTU:最大传输单元，由不同的数据链路层对应物理层产生的（硬件规定），以太网的MTU＝1500字节，即数据链路层发送的帧中的数据大小不能超过1500，最小46。太大会一直占用传输线路，别的数据需要等待，太小会影响效率，需要一直切片，且需要包装各种头，导致实际发送数据并不多。
MSS：最大分节大小，为TCP数据包每次传输的最大数据分段大小,MSS的取值受限于MTU。

23.socket编写TCP协议的流程

参考文章>>

1.服务端创建socket，绑定IP地址和端口号（bind），之后注册监听（listen）。
2.客户端创建socket，对指定IP和端口号发送链接请求（connect）。
3.服务端socket接收到客户端socket发来的连接请求，被动打开，调用accept函数接收请求，建立连接
4.建立连接之后可以write（recv）和send
5.close关闭socket。
参考文章>>

24.ARP协议原理

参考文章>>
1、ARP，意思是地址解析协议。每一台主机在出厂的时候都会有一个唯一标识自己的物理地址，也就是MAC地址。每一台主机在本地的ARP 报文缓冲区里都会维护一张ARP 列表，里面存放的是IP 地址与MAC 地址的映射关系。

2、当源主机向目标主机发送数据包时，在数据链路层传输时需要知道目标主机的MAC 地址。因此，源主机 会首先在本地的ARP 列表中查询该目标主机IP 地址所对应的MAC 地址。如果存在，则说明查询成功，于是源主机便向这个MAC 地址发送数据包即可。
如果不存在，源主机会在本地网段内发起一个ARP 请求的广播包，用来查询目标主机IP 地址对应的MAC 地址。
该ARP 请求包里面包含了“源主机IP 地址、源主机MAC 地址、目标主机IP 地址”。

3、于是，在本地网段内的所有主机都会收到这个ARP 请求包。当主机收到这个ARP 请求包后，会首先提取出ARP 请求包里面的目标主机IP地址，查看这个IP 是否与自己的IP 一致，如果不一致，则丢弃这个请求包，不予理会。如果一致，则该主机便会将这个请求包里的源主机IP 地址和源主机MAC 地址一 一添加到本地的ARP 列表中（如果已经存在了，便会覆盖它）。然后，这台主机便会返回一个包含了本机MAC 地址的ARP 响应数据包给源主机，告诉它自己的MAC 地址。

4、源主机收到这个ARP 响应数据包后，将目标主机的IP 地址和MAC 地址一 一添加到自己的ARP 列表中。然后，便根据此信息进行数据的传输。如果源主机一直得不到ARP 响应数据包，则说明ARP 查询失败。

25.DNS解析过程

参考文章>>
参考文章>>

DNS解析过程：

1. 浏览器先检查自身缓存中有没有被解析过的这个域名对应的ip地址，如果有，解析结束。
2. 如果浏览器缓存中没有（专业点叫还没命中），浏览器会检查操作系统缓存中有没有对应的已解析过的结果。
3. 如果至此还没有命中域名，才会真正的请求本地域名服务器（LDNS）来解析这个域名，这台服务器一般在你的城市的某个角落，距离你不会很远，并且这台服务器的性能都很好，一般都会缓存域名解析结果，大约80%的域名解析到这里就完成了。
4. 如果LDNS仍然没有命中，就直接跳到Root Server（根DNS服务器） 域名服务器请求解析。
5. 根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址(qq.com，二级域名服务器)给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找qq.com域服务器，重复上面的动作，进行查询，直至找到www.qq.com主机。
6. LDNS会缓存域名及对应的IP。
7. LDNS把解析的结果返回给用户，用户根据缓存到本地系统缓存中，域名解析过程至此结束。

- 主机向本地域名服务器的查询一般都是采用递归查询：
所谓递归查询就是：如果主机所询问的本地域名服务器不知道被查询的域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其它根域名服务器继续发出查询请求报文(即替主机继续查询)，而不是让主机自己进行下一步查询。因此，递归查询返回的查询结果或者是所要查询的IP地址，或者是报错，表示无法查询到所需的IP地址。

- 本地域名服务器向根域名服务器的查询的迭代查询：
迭代查询的特点：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的IP地址，要么告诉本地服务器：“你下一步应当向哪一个域名服务器进行查询”。然后让本地服务器进行后续的查询。
根域名服务器通常是把自己知道的顶级域名服务器的IP地址告诉本地域名服务器，让本地域名服务器再向顶级域名服务器查询。顶级域名服务器在收到本地域名服务器的查询请求后，要么给出所要查询的IP地址，要么告诉本地服务器下一步应当向哪一个权限域名服务器进行查询。最后，知道了所要解析的IP地址或报错，然后把这个结果返回给发起查询的主机。

DNS采用什么协议：
DNS在区域传输的时候使用TCP协议，其他时候使用UDP协议。

DNS区域传输的时候使用TCP协议：
原因1.辅域名服务器会定时（一般3小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，会执行一次区域传送，进行数据同步。区域传送使用TCP而不是UDP，因为数据同步传送的数据量比一个请求应答的数据量要多得多。
原因2.TCP是一种可靠连接，保证了数据的准确性。

域名解析时使用UDP协议：
客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。不用经过三次握手，这样DNS服务器负载更低，响应更快。理论上说，客户端也可以指定向DNS服务器查询时用TCP，但事实上，很多DNS服务器进行配置的时候，仅支持UDP查询包。

26.1 TCP与UDP的优缺点

TCP的优点： 可靠，稳定 TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源。 TCP的缺点： 慢，效率低，占用系统资源高，易被攻击 TCP在传递数据之前，要先建连接，这会消耗时间，而且在数据传递时，确认机制、重传机制、拥塞控制机制等都会消耗大量的时间，而且要在每台设备上维护所有的传输连接，事实上，每个连接都会占用系统的CPU、内存等硬件资源。 而且，因为TCP有确认机制、三次握手机制，这些也导致TCP容易被人利用，实现DOS、DDOS、CC等攻击。

UDP的优点： 快，比TCP稍安全 UDP没有TCP的握手、确认、窗口、重传、拥塞控制等机制，UDP是一个无状态的传输协议，所以它在传递数据时非常快。没有TCP的这些机制，UDP较TCP被攻击者利用的漏洞就要少一些。但UDP也是无法避免攻击的，比如：UDP Flood攻击…… UDP的缺点： 不可靠，不稳定 因为UDP没有TCP那些可靠的机制，在数据传递时，如果网络质量不好，就会很容易丢包。 基于上面的优缺点，那么： 什么时候应该使用TCP： 当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。 在日常生活中，常见使用TCP协议的应用如下： 浏览器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ文件传输 ………… 什么时候应该使用UDP： 当对网络通讯质量要求不高的时候，要求网络通讯速度能尽量的快，这时就可以使用UDP。 比如，日常生活中，常见使用UDP协议的应用如下： QQ语音 QQ视频 TFTP ……

有些应用场景对可靠性要求不高会用到UPD，比如长视频，要求速率

小结TCP与UDP的区别：

1.基于连接与无连接；
2.对系统资源的要求（TCP较多，UDP少）；
3.UDP程序结构较简单；
4.流模式与数据报模式 ；

5.TCP保证数据正确性，UDP可能丢包，TCP保证数据顺序，UDP不保证。

tcp协议和udp协议的差别
TCP UDP
是否连接 面向连接 面向非连接
传输可靠性 可靠 不可靠
应用场合 传输大量数据 少量数据
速度 慢 快

TCP与UDP区别总结：

1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接

2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付

3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的

UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）

4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信

5、TCP首部开销20字节;UDP的首部开销小，只有8个字节
6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

26.TCP/UDP的区别

TCP面向对象的含义：============>
连接建立：TCP需要三次握手，UDP不需要任何准备就可以传输数据。因此UDP更快速。
连接状态：TCP需要维护连接状态，包括发送接收缓存，拥塞控制参数以及序号与确认号参数，UDP不维护连接状态，也不追踪这些参数。

参考文章>>
TCP与UDP的区别主要表现在以下几个方面：

1）TCP是面向连接的传输控制协议，而UDP提供的是无连接的数据报服务；

2）TCP是一种流模式的协议，UDP是一种数据报模式的协议；

3）TCP具有高可靠性，确保传输数据的正确性，不出现丢失或乱序；UDP在传输数据前不建立连接，不对数据报进行检查和修改，无需等待对方的应答，所以会出现分组丢失、重复、乱序，应用程序需要负责传输可靠性方面的所有工作；

4）TCP对系统资源要求较多，UDP要求较少；

5）UDP具有较好的实时性，工作效率比TCP高；

6）UDP的包头结构比TCP的包头结构简单，因此网络开销也小；

7）TCP提供流量/拥塞控制，而UDP不提供。

UDP：
1）UDP无连接，时间上不存在建立连接需要的时延。DNS基于UDP
2）TCP首部20字节，UDP首部8字节。
3）UDP没有拥塞控制和流量控制
4）UDP是面向报文的，对应用层交下来的报文，添加首部后直接乡下交付为IP层，既不合并，也不拆分，保留这些报文的边界。对IP层交上来UDP用户数据报，在去除首部后就原封不动地交付给上层应用进程，报文不可分割，是UDP数据报处理的最小单位。
5）UDP常用一次性传输比较少量数据的网络应用，如DNS,SNMP等。

UDP特点：

• 每个分组都携带完整的目的地址；
• 发送数据之前不需要建立链接；
• 不对数据包的顺序进行检查，不能保证分组的先后顺序；
• 不进行分组出错的恢复和重传；
• 不保证数据传输的可靠性。

26.UDP如何保证可靠传输

参考文章>>
1、UDP报文丢失问题：
  因为UDP自身的特点，决定了UDP会相对于TCP存在一些难以解决的问题。第一个就是UDP报文缺失问题。在UDP服务器客户端的例子中，如果客户端发送的数据丢失，服务器会一直等待，直到客户端的合法数据过来。如果服务器的响应在中间被路由丢弃，则客户端会一直阻塞，直到服务器数据过来。
【问题解决方法】：
使用信号SIGALRM为recvfrom设置超时。首先我们为SIGALARM建立一个信号处理函数，并在每次调用前通过alarm设置一个5秒的超时。如果recvfrom被我们的信号处理函数中断了，那就超时重发信息；若正常读到数据了，就关闭报警时钟并继续进行下去；
使用select为recvfrom设置超时。
2、UDP报文乱序问题：
所谓乱序就是发送数据的顺序和接收数据的顺序不一致，例如发送数据的顺序为A、B、C，但是接收到的数据顺序却为：A、C、B。产生这个问题的原因在于，每个数据报走的路由并不一样，有的路由顺畅，有的却拥塞，这导致每个数据报到达目的地的顺序就不一样了。UDP协议并不保证数据报的按序接收。
【问题解决方法】：发送端在发送数据时加入数据报序号，这样接收端接收到报文后可以先检查数据报的序号，并将它们按序排队，形成有序的数据报。
3、UDP流量控制问题：
  总所周知，TCP有滑动窗口进行流量控制和拥塞控制，反观UDP因为其特点无法做到。UDP接收数据时直接将数据放进缓冲区内，如果用户没有及时将缓冲区的内容复制出来放好的话，后面的到来的数据会接着往缓冲区放，当缓冲区满时，后来的到的数据就会覆盖先来的数据而造成数据丢失（因为内核使用的UDP缓冲区是环形缓冲区）。因此，一旦发送方在某个时间点爆发性发送消息，接收方将因为来不及接收而发生信息丢失。
【问题解决方法】：解决方法一般采用增大UDP缓冲区，使得接收方的接收能力大于发送方的发送能力。

UDP如何保证可靠传输：
  由于在传输层UDP已经是不可靠的连接，那就要在应用层自己实现一些保障可靠传输的机制。简单来讲，要使用UDP来构建可靠的面向连接的数据传输，就要实现类似于TCP协议的：
超时重传（定时器）【解决报文丢失问题】；
有序接受 （添加包序号）【解决包乱序问题】；
应答确认 （Seq/Ack应答机制）【保证可靠性】；
滑动窗口流量控制等机制 （滑动窗口协议）【解决流量控制问题】。

UDP改进网络—UDT

目前已经有一些实现UDP可靠传输的机制，比如UDT（UDP-based Data Transfer Protocol）：基于UDP的数据传输协议（UDP-based Data Transfer Protocol，简称UDT）是一种互联网数据传输协议。UDT的主要目的是支持高速广域网上的海量数据传输，而互联网上的标准数据传输协议TCP在高带宽长距离网络上性能很差。 顾名思义，UDT建于UDP之上，并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。 由于UDT完全在UDP上实现，它也可以应用在除了高速数据传输之外的其它应用领域，例如点到点技术（P2P），防火墙穿透，多媒体数据传输等等。

27.TCP协议：reset

RST标志位
RST表示复位，用来异常的关闭连接，在TCP的设计中它是不可或缺的。就像上面说的一样，发送RST包关闭连接时，不必等缓冲区的包都发出去（不像上面的FIN包），直接就丢弃缓存区的包发送RST包。而接收端收到RST包后，也不必发送ACK包来确认。

几种情形：

• 1，客户端尝试与服务器未对外提供服务的端口建立TCP连接，服务器将会直接向客户端发送reset报文。
• 2，客户端和服务器的某一方在交互的过程中发生异常（如程序崩溃等），该方系统将向对端发送TCP reset报文，告之对方释放相关的TCP连接。
• 3，接收端收到TCP报文，但是发现该TCP的报文，并不在其已建立的TCP连接列表内，则其直接向对端发送reset报文。
• 4，在交互的双方中的某一方长期未收到来自对方的确认报文，则其在超出一定的重传次数或时间后，会主动向对端发送reset报文释放该TCP连接。
• 5，有些应用开发者在设计应用系统时，会利用reset报文快速释放已经完成数据交互的TCP连接，以提高业务交互的效率。
  参考文章>>
  参考文章>>

28.如何通过局域网获得另一台电脑的一个文件

参考文章>>

29.ARQ协议

参考文章>>
自动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中数据链路层的错误纠正协议之一。
ARQ包括：停止等待ARQ协议、回退ARQ和连续ARQ协议，错误检测（Error Detection）、正面确认（Positive Acknowledgment）、超时重传（Retransmission after Timeout）和 负面确认及重传（Negative Acknowledgment and Retransmission）等机制。

传统自动重传请求分成为三种：停等式(stop-and-wait）ARQ，回退n帧（go-back-n）ARQ，以及选择性重传（selective repeat）ARQ。后两种协议是滑动窗口技术与请求重发技术的结合，由于窗口尺寸开到足够大时，帧在线路上可以连续地流动，因此又称其为连续ARQ协议。三者的区别在于对于出错的数据报文的处理机制不同。三种ARQ协议中，复杂性递增，效率也递增。除了传统的ARQ，还有混合ARQ（Hybrid-ARQ）。

非连续ARQ协议：
1.停等式：
停止并等待协议的工作原理如下：

• 发送点对接收点发送数据包，然后等待接收点回复ACK并且开始计时。
• 在等待过程中，发送点停止发送新的数据包。
• 当数据包没有成功被接收点接收时，接收点不会发送ACK. 这样发送点在等待指定时间后，重新发送数据包。
• 反复以上步骤直到收到从接收点发送的ACK.

连续ARQ协议：
1.回退N帧协议:
在回退n帧的ARQ中，当发送方接收到接收方的状态报告指示报文出错后，发送方将重传过去的n个报文。回退N，发送窗口大于1，接收窗口等于1。允许发送方可以连续发送信息帧，但是，一旦某帧发生错误，必须重新发送该帧及其后的n帧。这种方式提高了信道的利用率，但允许已发送有待于确认的帧越多，可能要退回来重发的帧也越多。
3.选择重传协议（Selective Repeat):
发送点连续发送数据包但对每个数据包都设有个一个计时器。
当在一定时间内没有收到某个数据包的ACK时，发送点只重新发送那个没有ACK的数据包，这个方法的缺点是接收点收到的数据包的顺序可能不是发送的数据包顺序。因此在数据包里必须含有顺序字符来帮助接受点来排序。

• 接收点丢弃从第一个没有收到的数据包开始的所有数据包。
• 发送点收到NACK后，从NACK中指明的数据包开始重新发送

30.TCP的滑动窗口

滑动窗口的三个动作：

• 窗口左边沿向右边沿靠近为窗口合拢。这种现象发生在数据被发送和确认时。
• 当窗口右边沿向右移动时将允许发送更多的数据，我们称之为窗口张开。这种现象发生在另一端的接收进程读取已经确认的数据并释放了T C P的接收缓存时。
• 当右边缘向左移动时，称之为窗口收缩。

窗口有3种动作：展开（右边向右），合拢（左边向右），收缩（右边向左）这三种动作受接收端的控制。
合拢：表示已经收到相应字节的确认了
展开：表示允许缓存发送更多的字节
收缩（非常不希望出现的，某些实现是禁止的）：表示本来可以发送的，现在不能发送；但是如果收缩的是那些已经发出的，就会有问题；为了避免，收端会等待到缓存中有更多缓存空间时才进行通信。
TCP通过滑动窗口进行流量控制：
1、流量控制是管理两端的流量，以免会产生发送过快导致收端溢出，或者因收端处理太快而浪费时间的状态。用的是：滑动窗口，以字节为单位。
2.发端窗口的大小取决于收端的窗口大小rwnd（TCP报文的窗口大小字段）和拥塞窗口大小cwnd（见拥塞控制），发端窗口大小 = min{ rwnd , cwnd };

31. TCP的保活机制

为什么需要保活机制：
1.怎么判断对方是否还在线。这是因为，TCP对于非正常断开的连接系统并不能侦测到（比如网线断掉）。
2.长时间没有任何数据发送，连接可能会被中断。这是因为，网络连接中间可能会经过路由器、防火墙等设备，而这些有可能会对长时间没有活动的连接断掉。
保活机制的实现：
保活机制是由一个保活计时器实现的。当计时器被激发，连接一段将发送一个保活探测报文，另一端接收报文的同时会发送一个ACK作为响应。

保活时间：默认7200秒（2小时）
保活时间间隔：默认75秒
保活探测数：默认9次

客户端一般处于下面四种状态：
客户主机依然正常运行，并从服务器可达。客户的TCP响应正常，而服务器也知道对方是正常的，服务器在两小时后将保活定时器复位。
客户主机已经崩溃，并且关闭或者正在重新启动。在任何一种情况下，客户的TCP都没有响应。服务端将不能收到对探测的响应，并在75秒后超时。服务器总共发送10个这样的探测 ，每个间隔75秒。如果服务器没有收到一个响应，它就认为客户主机已经关闭并终止连接。
客户主机崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连接。
客户机正常运行，但是服务器不可达，这种情况与2类似，TCP能发现的就是没有收到探查的响应。
保活机制的弊端：
在出现短暂的网络错误的时候，保活机制会使一个好的连接断开；
保活机制会占用不必要的带宽；
解决方案：保活功能在默认情况下是关闭的。没有经过应用层的请求，Linux系统不会提供保活功能。

32.socket编程中TCP三次握手

1.基于TCP的socket

• 客户端connect函数发起三次握手
• 服务端listen接受三次握手

三次握手后服务器端和客户端成功建立起连接(准确讲是成功交换了彼此说话的起始序号)，服务器和相应客户端的连接信息会被放到操作系统的等待队列中，因为一个服务器可以和多个客户端建立连接，三次握手成功后需要维护这些客户端的连接信息，因此这些信息通常是操作系统用队列来维护的。

accept函数的作用：，服务器端调用accept函数后会从队列中取出一个已经成功三次握手的连接数据，此后双方就可以进行正常通信了。

accept函数不会影响三次握手，但该函数能否很快返回是和三次握手有关的。只有当三次握手完成后发生了通信的连接，才会被accept取出。

33.UDP如何实现一对多

基于UDP(面向对象)的socket编程的服务器端程序如下：
1、创建套接字（socket）
2、将套接字绑定到一个本地地址和端口上（bind）
3、等待接收数据（recvfrom）
4、关闭套接字

基于UDP(面向对象)的socket编程的客户端程序如下：
1、创建套接字（socket）
2、填充服务器地址
3、向服务器发送数据（sendto） 没有connect环节，无连接状态，知道服务器IP+端口号就能发送。
4、关闭套接字

基于UDP的socket编程：
服务端：
建套接字(socket)–>填充本地信息(sockaddr_in)–>把socket与IP地址加端口号绑定在一起（bind）–>接收(recvfrom)和回发(sendto)。
客户端：
创建套接字(socket)–>填充服务器的地址信息(sockaddr_in)–>发送(sendto)和接收回显(recvfrom)
源代码参考>>

34.TCP/IP模型各层的网络攻击

参考文章>>

35.TIME_WAIT过多

从服务器来讲，短时间内关闭了大量的Client连接，就会造成服务器上出现大量TIME_WAIT连接，严重消耗着服务器的资源，此时部分客户端就会显示连接不上。
从客户端来讲，客户端TIME_WAIT过多，就会导致端口资源被占用，因为端口就65536个，被占满就会导致无法创建新的连接。
解决办法：

• 服务器可以设置 SO_REUSEADDR 套接字选项来避免 TIME_WAIT状态，此套接字选项告诉内核，即使此端口正忙（处于TIME_WAIT状态），也请继续并重用它。
• 调整系统内核参数，修改**/etc/sysctl.conf文件，即修改 net.ipv4.tcp_tw_reuse 和 tcp_timestamps。net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets**重新用于新的TCP连 接，默认为0，表示关闭； net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为 0，表示关闭。
• 强制关闭，发送 RST 包越过TIME_WAIT状态，直接进入CLOSED状态

36.TIME_WAIT过多如何排查

1.首先 使用命令netstat -n | awk ，查看当前各种状态的数量

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT 15586
CLOSE_WAIT 343
ESTABLISHED 581

2.使用 netstat -anp |grep TIME_WAIT | head定位TIME_WAIT的

netstat -anp |grep TIME_WAIT | head
tcp        0      0 127.0.0.1:37545             127.0.0.1:50000             TIME_WAIT   -                   
tcp        0      0 127.0.0.1:40285             127.0.0.1:50000             TIME_WAIT   -                   
tcp        0      0 127.0.0.1:57127             127.0.0.1:50000             TIME_WAIT   -                   
tcp        0      0 127.0.0.1:34796             127.0.0.1:50000             TIME_WAIT   -                   

37.CLOSE_WAIT产生的原因及解决

被动关闭的一方未发FIN导致其一直处于CLOSE_WAIT。
原因：

• 被动关闭的一方还用数据没有发完，导致FIN没发。
• 被动关闭的一方阻塞在IO处。
• 服务端没有调用TCP的close(socket)。

解决：
一是对服务端代码进行改善，查看服务端代码在处理完毕客户端请求，并在客户端数据处理完毕后，有没有进行使用close(socket)操作.

二是使用keepalive保活机制来对这种半关闭连接进行检测

int keepAlive = 1;//开启keepalive属性
int keepIdle = 60;//如果60秒内没有任何数据往来，则进行探测
int keepInterval = 6;//探测时发包的时间间隔为6秒
int keepCount = 3;//探测尝试的次数，如果第一次探测包就收到相应，以后的2次就不再发
//keepalive
setsockopt(m_iSock,SOL_SOCKET, SO_KEEPALIVE, (void*)&keepAlive, sizeof(int));
setsockopt(m_iSock,SOL_TCP,TCP_KEEPIDLE,(void*)&keepIdle, sizeof(int));
setsockopt(m_iSock,SOL_TCP, TCP_KEEPINTVL,(void*)&keepInterval,sizeof(int));
setsockopt(m_iSock,SOL_TCP, TCP_KEEPCNT,(void*)&keepCount,sizeof(int));

38.数据包从一个主机发送到另一个主机

参考文章>>

39.IPV6和IPV4

IPV6 共2的128次方个IP地址
IPV4 共2的32次方个IP地址

IPV6的优点：

• 1.ipv6的地址数量是2的128次方个，完全够用
• 2.IPv6具有更高的安全性通过IPv6协议的安全机制，可对网络层的数据进行加密，对IP报文进行校验，这提高了数据的安全性。
• 3.IPV6传输速度更快IPv6的地址分配一开始就遵循聚类的原则，这大大减小了路由器中路由表的长度，提高了路由器转发数据包的速度。
• 4.IPv6还拥有更好的头部格式，IPV6使用新的头部格式，其选项与基本头部分开，这简化和加速了路由选择过程，提高了效率。

40.TCP超时重传的次数限制

参考文章>>

HTTP

1.HTTP/HTTPS

HTTP/HTTPS对比>>
HTTP是明文传输的，传输过程中容易被拦截、修改或者伪造请求；HTTPS则是在HTTP基础上进行进行了一些信息保护，相比HTTP来说更为安全。

HTTP的缺点：
使用明文通信，一些重要的内容会被窃听（密码）。
不能验证对方的身份，可能是伪造的信息。
无法验证报文的完整性，有可能已经被修改。

HTTPS如何解决HTTP的问题：
HTTPS 只是在 HTTP 的基础之上增加了加密处理、认证机制和完整性保护，即 HTTPS = HTTP + 加密 + 认证 + 完整性保护。
加密:HTTPS 通过对数据加密来使其免受窃听者对数据的监听，这就意味着当用户在浏览网站时，没有人能够监听他和网站之间的信息交换，或者跟踪用户的活动，访问记录等，从而窃取用户信息。
数据一致性:数据在传输的过程中不会被窃听者所修改，用户发送的数据会完整的传输到服务端，保证用户发的是什么，服务器接收的就是什么。
身份认证:是指确认对方的真实身份，也就是证明你是你（可以比作人脸识别），它可以防止中间人攻击并建立用户信任。

1.HTTP详解

详解文章>>
请求报文的格式

响应报文的格式

2.对称加密和非对称加密

参考文章>>
非对称加密指的是：加密和解密使用不同的秘钥，一把作为公开的公钥，另一把作为私钥。公钥加密的信息，只有私钥才能解密。私钥加密的信息，只有公钥才能解密。常见的非对称加密算法：RSA，ECC。
对称加密：指的就是加密和解密使用同一个秘钥，所以叫做对称加密。对称加密只有一个秘钥，作为私钥。常见的对称加密算法：DES，AES，3DES等等。
对称加密算法相比非对称加密算法来说，加解密的效率要高得多。但是缺陷在于对于秘钥的管理上，以及在非安全信道中通讯时，密钥交换的安全性不能保障。所以在实际的网络环境中，会将两者混合使用.

3.HTTPS的握手方式

SSL协议：SSL是“Secure Sockets Layer”的缩写，中文叫做“安全套接层”，其出现就是为了解决HTTP传输不安全的问题。
SSL协议的作用：

• 认证用户和服务器，确保数据发送到正确的客户端和服务器；
• 加密数据以防止数据中途被窃取；
• 维护数据的完整性，确保数据在传输过程中不被改变。

流程：

• 1.客户端给服务端发送一个报文，报文中包括：客户端能支持的TLS的最高版本，一个随机数A，客户端所能支持的加密算法集合以及压缩算法集合。

• 2.服务端收到客户端的报文后，根据报文中的TLS（SSL）版本，确定一个TLS版本，自己生成个随机数B，从客户端传过来的加密算法集合中挑一个具体的加密算法M（包括：非对称加密算法用于加密上图的pre-mastersecret，比如RSA算法、对称加密算法用于数据传输时双方使用的加密自己的内容解密对方内容的依据、MAC算法用于校验信息是否被篡改、伪随机算法用于生成最终通讯时对称加密算法所需要的密钥mastersecret），从压缩算法集合中挑一个具体的压缩算法N。然后发送一个响应包给客户端，这个报文就包含刚才提到的：TLS的版本，随机数B，加密算法M，压缩算法N。

• 3.第一步和第二步协商好了握手过程中需要的算法。

• 4.网站的管理员需要向CA机构进行申请，将自己的公钥提交给CA机构。CA机构则会使用我们提交的公钥，再加上一系列其他的信息，如网站域名****、有效时长等，来制作证书。

• 5.证书制作完成后，CA机构会使用自己的私钥对其加密，并将加密后的数据返回给我们，我们只需要将获得的加密数据配置到网站服务器上即可。

• 6.然后，每当有浏览器请求我们的网站时，首先会将这段加密数据返回给浏览器，此时浏览器会用CA机构的公钥来对这段数据解密。

• 7.如果能解密成功，就可以得到CA机构给我们网站颁发的证书了，其中当然也包括了我们网站的公钥。

参考文章>>

4.XSS攻击：

XSS攻击通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。
最常见的几种分类：反射型（非持久型）XSS、存储型（持久型）XSS、DOM型XSS、通用型XSS、突变型XSS。
参考文章>>

5.GET方法与POST方法的区别

1.GET提交的数据会放在URL之后，也就是请求行里面，以?分割URL和传输数据，参数之间以&相连，如EditBook?name=test1&id=123456.（请求头里面那个content-type做的这种参数形式） POST方法是把提交的数据放在HTTP包的请求体中。
2.GET提交的数据大小有限制（因为浏览器对URL的长度有限制），而POST方法提交的数据没有限制.
3.GET方法用于信息获取，它是安全的（安全：指非修改信息，如数据库方面的信息），而POST方法是用于修改服务器上资源的请求；
4.GET请求的数据会附在URL之后，而POST方法提交的数据则放置在HTTP报文实体的主体里，所以POST方法的安全性比GET方法要高；
5.GET方法传输的数据量一般限制在2KB，其原因在于：GET是通过URL提交数据，而URL本身对于数据没有限制，但是不同的浏览器对于URL是有限制的，比如IE浏览器对于URL的限制为2KB，而Chrome，FireFox浏览器理论上对于URL是没有限制的，它真正的限制取决于操作系统本身；POST方法对于数据大小是无限制的，真正影响到数据大小的是服务器处理程序的能力。
使用上的区别：
GET使用URL或Cookie传参，而POST将数据放在BODY中”，这个是因为HTTP协议用法的约定。
GET方式提交的数据有长度限制，则POST的数据则可以非常大”，这个是因为它们使用的操作系统
和浏览器设置的不同引起的区别。
POST比GET安全，因为数据在地址栏上不可见”，这个说法没毛病，但依然不是GET和POST本身的区别。

本质区别：
GET和POST最大的区别主要是GET请求是幂等性的，POST请求不是。这个是它们本质区别。
幂等性是指一次和多次请求某一个资源应该具有同样的副作用。简单来说意味着对同一URL的多个请求应该返回同样的结果。

9.云计算

云计算（cloud computing）是分布式计算的一种，指的是通过网络“云”将巨大的数据计算处理程序分解成无数个小程序，然后，通过多部服务器组成的系统进行处理和分析这些小程序得到结果并返回给用户。云计算早期，简单地说，就是简单的分布式计算，解决任务分发，并进行计算结果的合并。因而，云计算又称为网格计算。通过这项技术，可以在很短的时间内（几秒钟）完成对数以万计的数据的处理，从而达到强大的网络服务。
现阶段所说的云服务已经不单单是一种分布式计算，而是分布式计算、效用计算、负载均衡、并行计算、网络存储、热备份冗杂和虚拟化等计算机技术混合演进并跃升的结果。

10.https如何保证公钥可信性

参考文章>>
CA机构专门用于给各个网站签发数字证书，从而保证浏览器可以安全地获得各个网站的公钥。

• 网站的管理员需要向CA机构进行申请，将自己的公钥提交给CA机构。CA机构则会使用我们提交的公钥，再加上一系列其他的信息，如网站域名****、有效时长等，来制作证书。

• 证书制作完成后，CA机构会使用自己的私钥对其加密，并将加密后的数据返回给我们，我们只需要将获得的加密数据配置到网站服务器上即可。

• 然后，每当有浏览器请求我们的网站时，首先会将这段加密数据返回给浏览器，此时浏览器会用CA机构的公钥来对这段数据解密。

• 如果能解密成功，就可以得到CA机构给我们网站颁发的证书了，其中当然也包括了我们网站的公钥。

• 如果无法解密成功，则说明此段加密数据并不是由一个合法的CA机构使用私钥加密而来的，有可能是被篡改了，于是会在浏览器上显示一个著名的异常界面，如下图所示。

问题1：有了CA机构之后就真的安全了吗？我们在浏览器端要使用CA机构的公钥来解密数据，那么又该如何安全地获取到CA机构的公钥呢？

• 这个问题就很好解决了，因为世界上的网站是无限多的，而CA机构总共就那么几家。任何正版操作系统都会将所有主流CA机构的公钥内置到操作系统当中，所以我们不用额外获取，解密时只需遍历系统中所有内置的CA机构的公钥，只要有任何一个公钥能够正常解密出数据，就说明它是合法的。

问题2：如果证书被替换怎么办？

• 可以看到，由于攻击者申请的证书也是由正规CA机构制作的，因此这段加密数据当然可以成功被解密。也正是因为这个原因，所有CA机构在制作的证书时除了网站的公钥外，还要包含许多其他数据，用来辅助进行校验，比如说网站的域名就是其中一项重要的数据。因为，即使加密数据可以被成功解密，但是最终解密出来的证书中包含的域名和浏览器正在请求的域名对不上，那么此时浏览器仍然会显示异常界面。

11.HTTP2.0

参考文章>>

12.HTTP1.1和HTTP2.0的区别

参考文章>>

• HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理
• Connection请求头的值为Keep-Alive时，客户端通知服务器返回本次请求结果后保持连接；Connection请求头的值为close时，客户端通知服务器返回本次请求结果后关闭连接。HTTP 1.1还提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。
• HTTP 1.1增加host字段,表示请求的服务器的IP地址或域名
• HTTP/1.1加入了一个新的状态码100（Continue），表示接受的请求正在处理

13.HTTP状态码301 与 302的区别

参考文章>>

301 表示被请求 url 永久转移到新的 url；302 表示被请求 url 临时转移到新的 url。
301 搜索引擎会索引新 url 和新 url 页面的内容；302 搜索引擎可能会索引旧 url 和 新 url 的页面内容。
302 的返回码可能被别人利用，劫持你的网址。因为搜索引擎索引他的网址，他返回 302 跳转到你的页面。

详细来说，301和302状态码都表示重定向，就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址可以从响应的Location首部中获取（用户看到的效果就是他输入的地址A瞬间变成了另一个地址B）——这是它们的共同点。他们的不同在于。301表示旧地址A的资源已经被永久地移除了（这个资源不可访问了），搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址；302表示旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。即网址显示旧网址A，但网页内容确实B的页面。

14. HTTP状态？Cookie 和 Session

参考>>
HTTP是一种无状态协议，即服务器不保留与客户交易时的任何状态。
也就是说，上一次的请求对这次的请求没有任何影响，服务端也不会对客户端上一次的请求进行任何记录处理。

HTTP协议的无状态性带来的问题：
用户登录后，切换到其他界面，进行操作，服务器端是无法判断是哪个用户登录的。 每次进行页面跳转的时候，得重新登录。

三、解决方案
1.Cookie
Cookie 是客户端的存储空间，由浏览器来维持。具体来说 cookie 机制采用的是在客户端保持状态的方案。

Cookie，有时也用其复数形式Cookies，指某些网站为了辨别用户身份、进行 session 跟踪而储存在用户本地终端上的数据（通常经过加密）。

Cookie 可以翻译为“小甜品，小饼干” ，Cookie 在网络系统中几乎无处不在，当我们浏览以前访问过的网站时，网页中可能会出现 ：你好 XXX，这会让我们感觉很亲切，就好像吃了一个小甜品一样。

Cookie 的实现过程：
Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息，通知客户端保存 Cookie，当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。
也就是 Cookie 是服务器生成的，但是发送给客户端，并且由客户端来保存。每次请求加上 Cookie就行了。服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。

2.Session
Session，中文经常翻译为会话，其本来的含义是指有始有终的一系列动作/消息，比如打电话是从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个 Session。然而当 Session 一词与网络协议相关联时，它又往往隐含了“面向连接”或“保持状态”这样两个含义。

Session 是另一种记录客户状态的机制，不同的是 Cookie 保存在客户端浏览器中，而 Session 保存在服务器上。

客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上，这就是 Session。客户端浏览器再次访问时，只需要从该 Session 中查找该客户的状态就可以了。

虽然 Session 保存在服务器，对客户端是透明的，它的正常运行仍然需要客户端浏览器的支持。这是因为 Session 需要使用Cookie 作为识别标志。HTTP协议是无状态的，Session 不能依据HTTP连接来判断是否为同一客户，因此服务器向客户端浏览器发送一个名为 JSESSIONID 的 Cookie，它的值为该 Session 的 id（即放在HTTP响应报文头部信息里的Set-Cookie）。Session依据该 Cookie 来识别是否为同一用户。

3.Cookie 和 Session 的区别
（1）Cookie 数据存放在客户的浏览器上，Session 数据放在服务器上；
（2）Cookie 不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗，考虑到安全应当使用 Session ；
（3）Session 会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能。考虑到减轻服务器性能方面，应当使用COOKIE；
（4）单个Cookie 在客户端的限制是3K，就是说一个站点在客户端存放的COOKIE不能超过3K；

Cookie 和 Session 应用场景：

（1）登录网站，今输入用户名密码登录了，第二天再打开很多情况下就直接打开了。这个时候用到的一个机制就是cookie。

（2）session一个场景是购物车，添加了商品之后客户端处可以知道添加了哪些商品，而服务器端如何判别呢，所以也需要存储一些信息就用到了session。