目录
服务器性能相关：
1.什么是高性能
2.项目中的连接数能到多少
3.电商的高并发是如何实现的https://www.zhihu.com/question/20978066
https://blog.csdn.net/weixin_36995644/article/details/96271385
相似题目：设计一个秒杀系统，口述 （这个问题没答好）
4.介绍一下服务器端开发需要注意的问题并给出自己的处理意见；
5.高性能的手段
6.Redis为什么能够做到单进程单线程，却那么高的性能
7.如果要实现一个服务器你要怎么实现
8.祯同步和状态同步区别和表现(弱网络，重连，开发难度，安全性)
TCP相关的
1.为什么TCP是三次握手而不是四次或者两次，为什么是四次挥手，而不是三次挥手
握手不是两次的原因：
防止已经失效的连接请求报文段突然传到服务器，造成错误。
例如：
失效的报文段在网络节点中停滞，
导致延迟，直到连接释放以后的某个时间点才到达服务器，
服务器以为A又发起了连接请求，
发送确认报文段，
如果没有第3次，B以为建立了连接，
就会等待A的数据，造成资源浪费，
如果3次握手的话，
B收不到A的确认，
就知道没有要建立连接
握手不是四次的原因：浪费资源
挥手不是三次的原因：因为可能服务端还有需要发送的数据，所以不能合并状态
2.讲讲TCP KeepAlive(保活机制,即心跳包) 如果连接已经建立，但是客户端出现故障了.
服务器收到一个客户机的报文段后会重置保活计时器，当超过2个小时没有收到客户机的回复，将会发送探测报文段给客户机，之后每隔75s发送一次探测报文段，若连续发了10个没有收到客户机的回复，便认为客户机出现故障，断开连接
3.为什么喜欢在应用层定义KeepAlive而不用TCP协议栈中自带的？(我回答更灵活,可以自定义配置比如消息类型，时间间隔，接收后的处理) http keepalive tcpkeepalice
https://zhuanlan.zhihu.com/p/28894266
- KeepAlive默认情况下是关闭的，可以被上层应用开启和关闭
- tcp_keepalive_time: KeepAlive的空闲时长，或者说每次正常发送心跳的周期，默认值为7200s（2小时）
- tcp_keepalive_intvl: KeepAlive探测包的发送间隔，默认值为75s
- tcp_keepalive_probes: 在tcp_keepalive_time之后，没有接收到对方确认，继续发送保活探测包次数，默认值为9（次）
也就是如果2个小时了双方都没通信，就发个prob试探一下。
- 应用层心跳包不依赖于传输层协议，无论传输层协议是TCP还是UDP都可以用
- 应用层心跳包可以定制，可以应对更复杂的情况或传输一些额外信息
- KeepAlive仅代表连接保持着，而心跳包往往还代表客户端可正常工作
4.TCP的整个流程（状态转换过程）
要求：不是简单的描述，而是将整个状态转换过程描述清楚... https://mp.weixin.qq.com/s/8t_KFtrrBkFyZKPJg_y6pw
另外的话，更细的点是从内核角度看待
对于服务器来说 创建传输控制块TCB：tcp连接表、指向发送和接收缓存的指针、指向重传的队列指针、当前的发送和接收序号close--收听（监听）
对于客户端来说 也是创建传输控制块TCB
5.为什么握手只需要三次，而挥手需要四次呢？
因为3次握手可以直接发SYN+ACK，确认报文段跟同步报文段是合一起发的，，所以有3次，挥手时服务器收到FIN时，可能还要数据要发，不能立即关闭连接，所以要先发ACK报文段，如果有数据的话要把数据都传完再发FIN，因为连接释放报文段跟确认报文段分开发，所以有4次
6.为什么挥手的时候，不能等待服务端全部传送完直接发送ACK+FIN呢？
因为这样客户机没有等到确认，会以为是超时，会进行超时重传
就像点外买时，商家要先确认订单，做好了送到了，再让我拿外卖，而不是等外卖做好了送到了，再确认并让我拿外卖
5.TCP粘包怎么处理？(按理说有序列号在，因为不会粘包吧)
TCP协议，在使用Socket发送数据的时候，每次发送一个包，接收端是完整的接受到一个包还是怎么样？如果是每发一个包，就接受一个包，为什么还会出现粘包问题，具体是怎么运行的？
tcp是流,没有界限.也就所所谓的包. 。在流传输中出现，UDP不会出现粘包，因为它有消息边界，有数据长度的边界。
现象是这样个现象，但TCP本来就是基于字节流而不是消息包的协议，它自己说的清清楚楚：我会把你的数据变成字节流发到对面去，而且保证顺序不会乱，但是你要自己搞定字节流解析。
所以这个问题其实就是“如何设计应用层协议的问题”。
而在TCP中，有两种粘包问题：
1 发送端需要等缓冲区满才发送出去，造成粘包
2 接收方不及时接收缓冲区的包，造成多个包接收1.由Nagle算法造成的发送端的粘包:Nagle算法是一种改善网络传输效率的算法.简单的说,当我们提交一段数据给TCP发送时,TCP并不立刻发送此段数据,而是等待一小段时间,看看在等待期间是否还有要发送的数据,若有则会一次把这两段数据发送出去.这是对Nagle算法一个简单的解释,详细的请看相关书籍.象C和D的情况就有可能是Nagle算法造成的.
2.接收端接收不及时造成的接收端粘包:TCP会把接收到的数据存在自己的缓冲区中,然后通知应用层取数据.当应用层由于某些原因不能及时的把TCP的数据取出来,就会造成TCP缓冲区中存放了几段数据.对于基于TCP开发的通讯程序,有个很重要的问题需要解决,就是封包和拆包.
1：什么是流传输协议？
打个比方，发送方一次或分多次send了“1234，567，890，abc....”这些数据，接收方每次recv时得到的数据可能是分成了以下这么多片段：123，45，67890，ab，c....，也可能是这样的片段12，345，678，90abc,...。所以在网络正常的情况下，TCP虽然能保证数据按序到达对方，但不保证每次到达的数据量跟发送的时候是一致的，因此应用层必须要处理这样的情况，而处理这种情况就只能在应用层的数据里加额外信息，TLV就是其中一种实现方式。
处理方式：1）格式化数据：每条数据有固定的格式（开始符、结束符），这种方法简单易行，但选择开始符和结束符的时候一定要注意每条数据的内部一定不能出现开始符或结束符；
2）发送长度：发送每条数据的时候，将数据的长度一并发送，比如可以选择每条数据的前4位是数据的长度，应用层处理时可以根据长度来判断每条数据的开始和结束。
6..讲讲TCP_Nodelay 和 TCP_quickack(只回答了Nodelay即关闭nagle算法)
Nagle 算法确实能够在数据包较小时提高网络带宽的利用率并减少 TCP 和 IP 协议头带来的额外开销，但是使用该算法也可能会导致应用层协议多次写入的数据被合并或者拆分发送，当接收方从 TCP 协议栈中读取数据时会发现不相关的数据出现在了同一个数据段中，应用层协议可能没有办法对它们进行拆分和重组。
7.TCP建立连接的过程实际上是再干嘛？
确知对方的存在
协商一些参数（最大窗口、是否使用窗口扩大选项和时间戳选项、服务质量……）
对运输实体资源进行分配（缓存大小、连接表中的项目……）
三次握手建立连接的首要目的是
同步序列号。只有同步了序列号才有可靠的传输，TCP 协议的许多特性都是依赖序列号实现的，比如流量控制、消息丢失后的重发等等，这也是三次握手中的报文被称为 SYN 的原因，因为 SYN 的全称就叫做 Synchronize Sequence Numbers。
8.为什么要分层呢？
TCP/ IP 协议簇中的 TCP 协议能够保证数据段（Segment）的可靠性和顺序，有了可靠的传输层协议之后，应用层协议就可以直接使用 TCP 协议传输数据，不在需要关心数据段的丢失和重复问题1。
IP 协议解决了数据包（Packet）的路由和传输，上层的 TCP 协议不再关注路由和寻址2，那么 TCP 协议解决的是传输的可靠性和顺序问题，上层不需要关心数据能否传输到目标进程，只要写入 TCP 协议的缓冲区的数据，协议栈几乎都能保证数据的送达。
9.如果客户端发送第一个syn服务器没有接收到，产生了丢包了怎么办？ 《TCP/IP协议族》
客户端发送 SYN 开启了三次握手，之后客户端连接的状态是 SYN_SENT，然后等待服务器回复 ACK 报文。正常情况下，服务器会在几毫秒内返回 ACK，但如果客户端迟迟没有收到 ACK 会怎么样呢？客户端会重发 SYN，重试的次数由
tcp_syn_retries参数控制，默认是 6 次：net.ipv4.tcp_syn_retries = 6第 1 次重试发生在 1 秒钟后，接着会以翻倍的方式在第 2、4、8、16、32 秒共做 6 次重试，最后一次重试会等待 64 秒，如果仍然没有返回 ACK，才会终止三次握手。所以，总耗时是 1+2+4+8+16+32+64=
127 秒，超过 2 分钟。如果这是一台有明确任务的服务器，你可以根据网络的稳定性和目标服务器的繁忙程度修改重试次数，调整客户端的三次握手时间上限。比如内网中通讯时，就可以适当调低重试次数，尽快把错误暴露给应用程序。
10.如果客户端第三次握手失败了，第三次ack信号没有到达服务端会发生什么情况。四次握手呢？
https://blog.csdn.net/qq_26222859/article/details/60955713
当客户端收到服务端的SYN+ACK应答后，其状态变为ESTABLISHED，并会发送ACK包给服务端，准备发送数据了。如果此时ACK在网络中丢失，过了超时计时器后，那么Server端会重新发送SYN+ACK包，重传次数根据/proc/sys/net/ipv4/tcp_synack_retries来指定，默认是5次。如果重传指定次数到了后，仍然未收到ACK应答，那么一段时间后，Server自动关闭这个连接。但是Client认为这个连接已经建立，如果Client端向Server写数据，Server端将以RST包响应，方能感知到Server的错误。
当失败时服务器并不会重传ack报文，而是直接发送RTS报文段，进入CLOSED状态。这样做的目的是为了防止SYN洪泛攻击。
9.TCP滑动窗口机制，拥塞避免算法，超时重传机制
12.tcp头部，TCP首部标志位 以及UDP包头
TCP包头 20字节 源端口 16位； 目标端口 16位； 序列号 32位； 回应序号 32位； TCP头长度 4位； reserved 6位； 控制代码 6位； 窗口大小 16位； 偏移量 16位； 校验和 16位； 选项 32位(可选)；
UDP包头 源端口 16位 目的端口 16位 长度 16位 校验和 16位
12.Tcp传输中是否会出现乱序包？怎么处理？
对于我们写代码来说，不需要考虑这件事，应该tcp已经帮我们做好了。通过确认机制。
13.TCP流量控制是通过接收端发送带有接受窗口剩余大小的ACK来实现的，那么如果接收端的TCP没有CPU调度会发送ACK吗，会不会因为接受窗口满了并且不能及时发送ACK导致数据丢失
14.tcp协议的一些缺陷，如果想要tcp的功能，又想要用udp的速度怎么做
TCP面临的主要问题是带宽资源的浪费。在互联网初期带宽资源不多，就好比路不宽不好，后来路在逐渐拓宽升级等，但是TCP这辆车却一直没有升级很多，就像一辆老旧汽车在高速路上无法快速飞奔。另一方面，有如下班高峰期的道路拥堵，网络拥塞也是TCP亟待解决的问题，这方面的研究可以堪比自动驾驶技术极大提升高速公路的车流量，使每一位司机都变成一位守规的开车人
TCP瓶颈的其他方面包括：
1）当应用不再需要时，TCP不必要的间歇抢占带宽与暴力发送会对正常的视频流传输带来极大干扰从而造成视频卡顿、非必要丢包等状况。
2）TCP鲁莽的重传也会导致不必要的数据重复发送，进而浪费宝贵的有限带宽资源。总而言之就是TCP流之间带宽共享无任何保护，带宽抢占近乎随机，使得带宽资源分配不合理，这种端到端的宽带资源利用与共享命题是40年来学术界公认的互联网最难解决的问题之一。
1）性能比UDP低，包括延迟时间等。
总体而言，TCP在传统的网络上工作的非常好，只是因为一些新的网络状况导致TCP不能很好的适应，这些就是需要改进的方向。
首先是流控算法不能很好的适应高带宽高延迟的场景，因为ack确认因为传输延迟不能及时送达导致传输速度远低于理论的传输带宽。
还有拥塞控制算法也不能很好的适应网络不太稳定的场景（比如无线网络），TCP的拥塞控制认为丢包是因为网络传输饱和，所以一但出现丢包就采取指数级避让，而无线网络因为短暂的信号干扰导致的丢包并不是因为网络传输饱和，此时采取指数级避让是不合适的，会导致无线传输的速度骤降。
关于这个已经有很多改进的算法了，比如BBR
TCP流控算法的关键，是基于丢包，有否丢包是唯一的判断依据，是加油门还是踩刹车。
但TCP由于对网络了解的很片面，无法分辨丢包是什么原因造成的 https://www.zhihu.com/question/47560918
1）网络真的拥堵而丢包
2）线路质量差CRC校验失败丢、或信号干扰丢
3）IP包乱序而引起的误判
15. 三次握手seq是随机的吗，如果两个进程随机的seq一样，服务端会发生什么
当一端为建立连接而发送它的SYN时，它为连接选择一个初始序号。ISN随时间而变化，因此每个连接都将具有不同的ISN。ISN可以看作是一个32比特的计数器，每4ms加1 。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它做错误的解释。
三次握手的其中一个重要功能是客户端和服务端交换 ISN(Initial Sequence Number)，以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。
17.TCP在连接握手的时候，是否携带报文数据（不携带）
为什么不能携带数据（防止服务端受到恶意攻击，如果每次握手可以携带数据，一些恶意请求在握手时携带大量垃圾数据包，服务端解析能力有限，请求较多时，会发生崩溃）
UDP相关的：
1.UDP如何实现不乱序
2.UDP如何实现不丢包
要实现文件的可靠传输，就必须在上层对数据丢包和乱序作特殊处理，必须要有要有丢包重发机制和超时机制。
模拟TCP协议，重发请求（ARQ）协议，它又可分为连续ARQ协议、选择重发ARQ协议、滑动窗口协议等等。
3.UDP之上怎么实现可靠传输
https://zhuanlan.zhihu.com/p/25622566
其他的
1.select,poll,epoll的区别(可移植性、最大监听数目、效率) ，优缺点 select和epoll函数的参数介绍一下
select的特点：select 选择句柄的时候，是遍历所有句柄，也就是说句柄有事件响应时，select需要遍历所有句柄才能获取到哪些句柄有事件通知，因此效率是非常低。但是如果连接很少的情况下， select和epoll的LT触发模式相比， 性能上差别不大。
这里要多说一句，select支持的句柄数是有限制的， 同时只支持1024个，这个是句柄集合限制的，如果超过这个限制，很可能导致溢出，而且非常不容易发现问题， TAF就出现过这个问题， 调试了n天，才发现：）当然可以通过修改linux的socket内核调整这个参数。
(1)select支持的句柄数量时有限的
(2)select将事件探测与事件响应夹再一起了，这样会降低对其他事件的探测..
(3)select的可移植性比较好
调用Select每次都需要将文件描述符进行遍历
调用select函数时需要向该函数传递监视对象的信息，
调用select之后会把除了发生变化的文件描述符对应位外，剩下的所有位都初始化位0.所以
epoll的特点：epoll对于句柄事件的选择不是遍历的，是事件响应的，就是句柄上事件来就马上选择出来，不需要遍历整个句柄链表，因此效率非常高，内核将句柄用红黑树保存的。
select和epoll的优点不是说对于单个连接的处理得更快，而是能够处理多个连接。
使用select主要在于如何动态维护 read_fd,write_fd以及expect_fd
现 elect（）函数中， readfds writefds exceptfds 同时作为输入参数和输出参数
FD_ZERO(int fd, fd_set * fds) ;
FD_SET(int fd, fd_set * fds) ;
FD_ISSET （int fd , fd_ set * fds) ;
FD_CLR(int fd, fd_set* fds) ;
int select(int nfds , fd_se t *readfds , fd_set *writefds, fd_set *exceptfds, struct
timeval meo t)2.epoll的底层原理以及主要函数，epoll优势在哪里，epoll要在应用层实现的话怎么实现
epoll通过结构体epoll_event将发生变化的文件描述符单独集中在一起.
另外epoll_event的作用是在使用epoll_ctl的时候在例程中注册文件描述符，用于注册关注的事件。
struct epoll_event{
__uint32_t events;
epoll_data_t data;
}
struct epoll_event event;
...
event.events = EPOLLIN;
event.data.fd = sockfd;
epoll_ctl(epfd,EPOLL_CTL_ADD,socketfd,&event);3.epoll的LT,ET模式的区别以及适用场景哪个阻塞哪个非阻塞，哪个效率高，为什么
epoll_create(2)， epoll_ctl(2)， epoll_wait(2)。
LT：水平触发，效率会低于ET触发，尤其在大并发，大流量的情况下。但是LT对代码编写要求比较低，不容易出现问题。LT模式服务编写上的表现是：只要有数据没有被获取，内核就不断通知你，因此不用担心事件丢失的情况。
ET：边缘触发，效率非常高，在并发，大流量的情况下，会比LT少很多epoll的系统调用，因此效率高。但是对编程要求高，需要细致的处理每个请求，否则容易发生丢失事件的情况。
在TCP/IP网络编程中，作者提到边缘触发的优点主要在于可以分离接收数据和处理数据的事件点。
下面举一个列子来说明LT和ET的区别（都是非阻塞模式，阻塞就不说了，效率太低）：
采用LT模式下， 如果accept调用有返回就可以马上建立当前这个连接了，再epoll_wait等待下次通知，和select一样。
但是对于ET而言，如果accpet调用有返回，除了建立当前这个连接外，不能马上就epoll_wait还需要继续循环accpet，直到返回-1，且errno==EAGAIN
ET编程的时候需要注意：
读取错误原因方法以及非阻塞模式下套接字的创建方法，
read函数返回--1，变量errno中的值weiEAGAIN时，说明没有数据可读。
4.怎么触发epoll的回调函数
5.回调函数的机制，实现以下回调函数
6.网络5种io模型
[1] blocking IO - 阻塞IO
[2] nonblocking IO - 非阻塞IO
[3] IO multiplexing - IO多路复用
[4] signal driven IO - 信号驱动IO
[5] asynchronous IO - 异步IO
7. reactor proactor 反应堆模式
8.为什么要TIME_WAIT？出现大量TIME_WAIT的原因？如何避免TIME_WAIT？TCP的timewait发生在什么时候以及作用.如果服务器中有大量的close_wait的端口,原因是什么,怎么解决
之所以需要TIME_WAIT,是因为要确保服务器是否已经收到了我们的 ACK 报文，如果没有收到的话，服务器会重新发 FIN 报文给客户端，客户端再次收到 FIN 报文之后，就知道之前的 ACK 报文丢失了，然后再次发送 ACK 报文。
出现大量TIME_WAIT的原因？
1.高TCP并发并且采用短连接方式进行通讯的通讯系统在高并发高负载下运行一段时间后，就常常会出现做为客户端的程序无法向服务端建立新的socket连接的情况。2.后面出现了很多TIME_WAIT状态，主要是由于一条请求是不正确的，所以HTTP请求会拒绝这条响应，服务器主动关闭连接，
为什么TIME_WAIT是2MSL？
客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。
1）TIME_WAIT确保有足够的时间让对端收到了ACK，如果被动关闭的那方没有收到Ack，就会触发
被动端重发Fin，一来一去正好2个MSL，2）有足够的时间让这个连接不会跟后面的连接混在一起（你要知道，有些自做主张的路由器会缓存IP数据包，如果连接被重用了，那么这些延迟收到的包就有可能会跟新连接混在一起）。
对应这样一种情况，最后客户端发送的
ACK = 1给服务端的过程中丢失了，服务端没收到，服务端怎么认为的？我已经发送完数据了，怎么客户端没回应我？是不是中途丢失了？然后服务端再次发起断开连接的请求，一个来回就是2MSL，这里的两个来回由那一个来回组成的？另外一种解释：其实是一样的
客户端给服务端发送的
ACK = 1丢失，服务端等待1MSL没收到，然后重新发送消息需要1MSL。如果再次接收到服务端的消息，则重启2MSL计时器，发送确认请求。客户端只需等待2MSL，如果没有再次收到服务端的消息，就说明服务端已经接收到自己确认消息；此时双方都关闭的连接，TCP 四次分手完毕。
总结：MSL是最长报文段寿命，最长生命周期，保证两个传输方向上尚未接收或者迟到的报文段已经消失，如果立刻重启服务可能会收到上个连接的报文段，造成错误保证最后一个ACK能够到达
这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接的插口（客户的IP地址和端口号，服务器的IP地址和端口号）不能再被使用。这个连接只能在2MSL结束后才能再被使用。
TIME-WAIT状态如果过多，会占用系统资源。Linux下有几个参数可以调整TIME-WAIT状态时间：
- net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭。
- net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。
- net.ipv4.tcp_max_tw_buckets = 5000表示系统同时保持TIME_WAIT套接字的最大数量，如果超过这个数字，TIME_WAIT套接字将立刻被清除并打印警告信息。默认为180000，改为5000。
在socket的TIME_WAIT状态结束之前，该socket所占用的本地端口号将一直无法释放。高TCP并发并且采用短连接方式进行通讯的通讯系统在高并发高负载下运行一段时间后，就常常会出现做为客户端的程序无法向服务端建立新的socket连接的情况。此时用“netstat -tanlp”命令查看系统将会发现机器上存在大量处于TIME_WAIT状态的socket连接，并且占用大量的本地端口号。最后，当该机器上的可用本地端口号被占完（或者达到用户可使用的文件句柄上限），而旧的大量处于TIME_WAIT状态的socket尚未被系统回收时，就会出现无法向服务端创建新的socket连接的情况。此时系统几乎停转，空有再好的性能也发挥不出来。解决TIME-WAIT状态过多的情况，一般做法是
打开系统的TIMEWAIT重用和快速回收。然而，主动进行关闭的链接才会进入TIME-WAIT状态，所以最好的办法：尽量不要让服务器主动关闭链接，除非一些异常情况，如客户端协议错误、客户端超时等等。解决方法？
- 修改TIME_WAIT连接状态的上限值
- 启动快速回收机制
- 开启复用机制
- 修改短连接为长连接方式
- 由客户端来主动断开连接
大量的Close_wait有什么危害呢？
大量
CLOSE_WAIT有什么危害?CLOSE_WAIT状态不会自己消失,除非对应的应用进程死掉,不会消失就意味着一直占用服务器资源,端口总数又只有65535,因此这里的服务器作为连接的发起者就会造成大量端口被占用,一旦占用完就导致后面的请求都发不出去,也就是一开始图上另一个项目发请求出现的Address already in use (Bind failed)错误.
出现大量CLOSE_WAIT的原因以及解决方案见 https://cloud.tencent.com/developer/article/1347610
9.报文文在网络中停留的时间大概是多久？
MSL是最长报文段寿命，最长生命周期，保证两个传输方向上尚未接收或者迟到的报文段已经消失，如果立刻重启服务可能会收到上个连接的报文段，造成错误保证最后一个ACK能够到达
RFC 793中规定MSL为2分钟，实际应用中常用的是30秒，1分钟和2分钟等。
10.select为什么限制1024？
- 问题一：select使用位域的方式来传递关心的文件描述符，位域就有最大长度，在Unix下是256，在Linux下是1024，好像可以调大，但是不方便
- 问题二：select使用位域的方式传回就绪的文件描述符，调用者需要循环遍历每一个位判断是否就绪，当文件描述符个数很多，但是空闲的文件描述符大大多于就绪的文件描述符的时候，效率很低。在这个问题上，poll也是一样的。
作者：用心阁
链接：https://www.zhihu.com/question/37219281/answer/74003967
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
12.UDP，TCP区别，适用场景； tcp连接，断开过程，连接攻击（半连接队列），解决办法 有个半连接状态，对应到具体哪步状态
服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。
当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。
这里再补充一点关于SYN-ACK 重传次数的问题：
服务器发送完SYN-ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传。如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。
注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s，2s，4s，8s……
另外半连接队列满之后，不是说就不能接受新的请求了
13.同步异步阻塞非阻塞？
网络编程：
1.send返回值
调用send函数的时候，做的操作实际上是把你给出的数据拷贝的系统的缓存中，然后等待系统发送，send函数的返回值就是实际拷贝进入系统缓存中的数据的大小，这个大小有可能小于你给定的数据大小，所以可能需要多次调用；
2. unix socket和raw socket(不知道）
3..讲讲非阻塞socket(老生常谈系列)
阻塞IO是指IO操作需要彻底完成之后才返回，只有当系统调用返回或者超时的是hi才返回结果。 非阻塞IO是指IO操作被调用后立即返回给用户一个状态值，不需要等到IO操作完成。
阻塞IO的缺点：你得创建多个线程或者进程才能够有并发量没所以一般不需要考虑
4.数据是怎么从内核态拷贝到用户态， 为什么要经历这个过程？
4.操作系统读写操作，写文件read的三种模式，写成功是怎样，什么情况下写操作会失败
对于网络IO（假设是read）发生时，他会涉及到两个对象，一个是调用它得进程，另外一个是系统内核。
1.等待数据准备的过程 2.将数据从内核态拷贝到用户态中
5.写过socket编程吗；tcp的三次握手对应哪些系统调用；
6.字节对齐，网络序与主机序
7.tcp/udp用到的各个接口函数
8.socket绑定地址0.0.0.0，127.0.1.1是在干嘛
https://gist.github.com/zxhfighter/b9f4b4ef328cd8b433b0e9dc2f4af26d
0.0.0.0表示的是本机上的任何ip，，就表示你的服务器监听在你本机的所有 IP 地址上，通过任何一个 IP地址 都可以访问到。
127.0.0.1 是本地localhost的ip地址，通常分配给 loopback 接口，用来测试本机的 TCP/IP 协议栈。loopback 是一个特殊的网络接口(可理解成虚拟网卡)
9.nagle算法 TCP场景下，如果传送多个小包，如何实现更优的传递
10.网络编程使用到的系统函数如下
fcntl( fd , F_SETFL , O_NONBLOCK );
signal(SIGCHID, )sigaction
11.read返回的各种值可以用来判断系统的状态
recv()>0 ，表示接收数据完毕，返回值时接收到的字节数
recv()=0， 表示连接已经正常断开
recv()=-1，且errno等于EAGAIN,表示recv操作还没执行完成
recv()=-1,且errno不等于EAGAIN,表示recv操作遇到系统错误errno
12.多进程服务器，多线程服务器
多进程服务器，每来一个客户端，就fork一个子进程来处理请求
while(1){
client_sock = accept(serv_sock,...)；
pid = fork();
if(pid = 0){
close(serv_sock);
while(read(...));
close(client_sock);
}
else{
close(client_sock);
}
}13.写一个echo服务器(最普通的，基于select，基于epoll的)
struct epoll_event *ep_events;
struct epoll_event event;
//创建epoll
epfd = epoll_create();
ep_events = malloc(sizeof(struct epoll_eveent) * EPOLL_SIZE);
event.events = EPOLLIN;
event.data.fd = serv_sock;
epoll_ctl(epfd,EPOLL_CTL_ADD,serv_sock,&event);
while(1){
event_cnt = epoll_wait(epfd,ep_events,EPOLL_SIZE,-1);
for(int i = 0 ; i < event_cnt ; i++){
if(eo_events[i].data.fd = serv_sock){
}
}
}HTTP:
HTTP请求格式：
HTTP相应格式:
状态行
消息头
消息体
traceroute是什么
输入一个域名的访问过程？
P头都有什么？详细一点？源地址和目标地址是MAC吗？
.交换机和路由器的区别，具体一点？广播风暴？
.http和https，SSL？加密解密？
1.HTTP包拆分后怎么组合
2.内网查询到百度流程
3.路由器是如何知道对应的ip地址和mac地址的
4.应用层如何保证包有序？粘包了解吗
5:http是怎样保持登录状态的，https和http的区别，为什么我们需要端口，比如http80https443我们为什么需要这个端口
6. 有get post之类的 还有什么指令
7..http常用方法
8..post请求返回的100状态码是协议规定的还是浏览器规定的
9.如何维护长连接状态
10.HTTP是明文传输，有什么方法解决安全性。
11.状态码说一下
12.http缓存的字段是哪个
13.头部字段介绍以下
http1.x和2.0的区别
14.无连接是什么 无状态是什么
15.content-type http报文段的有哪些东西 http状态码 get与post的区别
16.幂等 讲一下https SSL加密过程 公钥和私钥
17.get和post有哪些区别？（也是在项目里提及到的。回答的也不错，有个重点面试官会深问，get是一个tcp包，post是发俩tcp包，发的是什么，服务器回的什么状态码）
18.如怎么设计服务器的登陆，cookie的设计等等，更像是在考你的思考能力。
19.cookie session 禁用cookie 怎么办?如何实现cookie，session
20.get post 区别?get能把参数放body吗，post能把参数放在url里面吗
21什么情况下用http连接不用tcp
22http有状态吗？
23.RESTful是什么 框架
介绍一下一个B/S网站架构从用户使用浏览器打开网址后的整个过程
• 浏览器发生302跳转背后的逻辑？
• HTTP协议的交互流程。HTTP和HTTPS的差异，SSL的交互流程？
HTTPS:
1.HTTP与HTTPS的区别？
2.HTTPS加密传输过程？
3.私钥在传输过程中被截取怎么办？
4 HTTPS的多一次握手具体说
6..https怎么做到安全性的
7.密码学；中间人攻击、HTTPS、对称加密和非对称加密、dos攻击发生在TCP哪个阶段（直接说不会）
8.通信过程中安全性如何保证？加密时密钥如何分发保证不被中间人攻击？（忘了 gg）
9.数据传输时如何保证可靠性？消息摘要有什么作用？
5. wireshark用过吗？实现原理是什么？（完全不会）
6 HTTPS的握手流程和实现原理？加密过程？
7 对称会话公匙？为什么不采用非对称的？不会，面试官解答了，说是因为对称会话密匙效率更高。
8 非对称会话密匙的加密原理？
10.说一下https有什么加密方式（对称、非对称，只答了非对称），区别，其如何传输公钥保证公钥不被截获
12.http和https的区别，SSL怎么实现，如果对方伪造公钥怎么办？
环境调试：
1.关于tcpdump -i
2.关于gdb
用gdb调试，怎么定位到线程
3.关于strace工具
4.关于wireshare
5.有关网络的一些linux指令
Linux查看具体端口是否被占用
网络层：
- .ip包如何分辨是tcp还是udp
- 问路由器在OSI七层模型中的哪一层
- ping底层过程 ICMP协议
- NAT
https://mp.weixin.qq.com/s/H7Qx9W7W_CHZanGfsrWh9Q
- 网络安全：
- syn洪泛攻击，如何应对？
服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。
检测 SYN 攻击非常的方便，当你在服务器上看到大量的
半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。在 Linux/Unix 上可以使用系统自带的 netstat 命令来检测 SYN 攻击。netstat -n -p TCP | grep SYN_RECV常见的防御 SYN 攻击的方法有如下几种：
- 缩短超时（SYN Timeout）时间
- 增加最大半连接数
- 过滤网关防护
- SYN cookies技术
关于SYN Flood攻击。一些恶意的人就为此制造了SYN Flood攻击——给服务器发了一个SYN后，就下线了，于是服务器需要默认等
63s才会断开连接，这样，攻击者就可以把服务器的syn连接的队列耗尽，让正常的连接请求不能处理。于是，Linux下给了一个叫tcp_syncookies的参数来应对这个事——当SYN队列满了后，TCP会通过源地址端口、目标地址端口和时间戳打造出一个特别的Sequence Number发回去（又叫cookie），如果是攻击者则不会有响应，如果是正常连接，则会把这个 SYN Cookie发回来，然后服务端可以通过cookie建连接（即使你不在SYN队列中）。请注意，请先千万别用tcp_syncookies来处理正常的大负载的连接的情况。因为，synccookies是妥协版的TCP协议，并不严谨。对于正常的请求，你应该调整三个TCP参数可供你选择，第一个是：tcp_synack_retries可以用他来减少重试次数；第二个是：tcp_max_syn_backlog，可以增大SYN连接数；第三个是：tcp_abort_on_overflow处理不过来干脆就直接拒绝连接了。
- 子网掩码的作用（这个我有点忘了，就说了区分网络地址和主机地址，大网络分小网络）
- 浏览器输入网址后的整个过程
- DNS过程、基于什么协议、为什么用udp、dns截断
- 网关、网桥、路由器
- IPv4网段
- ip地址局域网到外网的转换
- DNS的实现过程、DNS截获
- ip地址的组成 http://blog.leanote.com/post/medusar/7e371ca28621
- DHCH的工作流程 （应用层协议，基于UDP）
https://mp.weixin.qq.com/s/2mSa_uMNURX56tW8DG5WnA
实际流程类似于如下比喻： 客户端寻求offer，各大DHCP说自己有offer，客户端选择其中一个offer， DHCP回复ack。
为什么DHCP采用UDP而不是TCP？ TCP需要建立连接，一开始连对方的IP都不知道，不可能通过对方的套接字建立连接。DHCP在执行期间，客户端和服务器都没有标识自己身份的IP地址，因此不可能通过单播的形式进行交互。
- CDN有了解过吗
- •负载均衡了解哪些算法（一致性hash） • 一致性hash 的好处，如果节点比较少会出现什么问题
APR协议
问：在局域网中，执行ping+一个公网地址，网络层及以下会发生什么
答：这个地方他提示了：icmp协议（要求回答具体执行机制），网关和路由器（要求回答具体发挥了什么作用），什么叫相邻结点，mac地址和ip地址的变化，包是如何发送的网关的（我？？？）
开放性题目：
1.一个用户一个小时内最多访问50个短视频，怎么在服务器设计？
服务器为每个用户维护一个deque,记录当前时间到一个小时前的的访问纪录，实时更新deque,频率1s
2.一个超大（几亿行数据）的日志文件，记录昨天的日活跃用户登录登出情况，每行三个信息：user_id, 登入时间轴（XXXs），登出时间轴（XXXs）（备注：uerid唯一、即当天该用户不会重复登录）
求两个值：一天内的同时在线人数峰值；这个峰值的活跃时长（即峰值的最大持续时间）
3.搜索引擎的工作原理3.情景设计，如何设计出类似百度搜索这样的搜索补全功能？大概说思路
4.注册中心服务判活
5.负载均衡
552
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
