1.UDP和TCP报文格式
UDP:
16位源端口号，16位目的端口号
16位UDP长度，16位UDP校验和
数据（有）
TCP：
16位源端口号，16位目的端口号
32位序列号
32位确认号
4位首部长度，6位保留位，URG，PSH，RST，SYN，ACK，FIN，16位窗口大小
16位校验和 ， 16位紧急指针
数据
2.UDP和TCP的区别
UDP：
无连接、支持一对一，一对多，多对一，多对多的交互通信、不可靠，没有拥塞控制，流量控制所以传输效率高、报文长度固定。首部开销8个字节。
TCP：
面向连接，点对点传输，可靠传输（确认应答，超时重传），面向字节流，动态报文（接收方窗口大小调整），首部开销20个字节。
3.SYN泛洪攻击
SYN泛洪攻击产生于TCP的三次握手中，在客户端恶意大量发送SYN请求，而不回复服务端确认连接。导致服务器需要等待一个timeout（分钟）时间才会重新发送，再收不到直接关闭。直接资源耗尽宕机崩溃。
处理：降低timeout时间，尽快释放半连接占用，短时收到IP相同SYN请求直接丢弃。或拉入黑名单。
4.为什么TCP不是两次？为什么不是四次？
TCP是一个全双工通信，必须确保通信双方都可以收发数据。
5.三次握手分别失败？
第一次握手失败：客户端会重新发送SYN请求
第二次握手失败：服务端会重新发送ACK和SYN请求，客户端也会发送SYN请求。（超时问题）
第三次握手失败：客户端也会发送ACK请求，超过超时计数器，服务器直接发送RST重置连接
6.四次挥手？
在采用TCP协议通信中，当数据传输完毕后，客户端向服务端发送FIN包，处于FINWAIT1状态，服务器向服务器回复ACK确认，处于CLOSE_WAIT状态。之后服务器再向客户端发送FIN包，处于LAST_ACK状态。客户端收到服务器发送的FIN包之后，向服务器发送最后一次ACK，如果发送成功，服务端关闭。
7.MSL时间？
最大报文段生存周期。在客户端四次挥手的最后一次客户端向服务器发送ACK后处于TIME_WAIT状态。客户端需要等待两个最大报文生命周期（MSL）确保可以收到服务器发送的FIN包。并且确保在2MSL中发送的数据包彻底消失在网络中。
8.http和https的区别？
HTTP协议是以明文的方式在网络中传输数据，HTTPS协议传输的数据是经过TLS加密，数据更具安全性。
HTTPS在TCP连接后，还要进行SSL的handshake，协商对称加密密钥
HTTP默认端口：80端口，HTTPS默认端口：443端口
HTTPS需要服务器申请证书
9.加密是在哪一层？
HTTP加密采用对称式加密。先用非对称加密生成公钥和私钥。在应用层生成。待三次握手建立连接之后，生成方将公钥发送出去，对方想要给发送方发送数据，就将公钥拿到将自己的如何对数据对称式加密算法进行加密，发送出去。发送方接收到就获取了双方的数据加密方式。
10.滑动窗口机制?
通信双方通过协议中的窗口字段，协商窗口大小。已接收方的可用窗口大小为基础。发送方和接收方的窗口都会维护三个指针前沿和后沿，发送数据截止地址。发送方将后沿与中间指针之间数据发送过去，接收方一旦接收到多条数据之后，如果中间没有丢失，前沿前移，就对每条数据回复ACK及可用窗口大小，发送方收到之后，就后沿前移，继续发送。
ACK丢失：如果接收方的ACK丢失，那也不用担心，因为它一有个规则就是，只会发送那些前面都收到的数据包的ACK，若中间数据没有收到，它不会发送后面数据的ACK。
数据丢失：发送丢失数据的序号，连续三次发送。发送方接收到后，才会重传。
11.UDP,TCP,HTTP报头与数据分离？
UDP报头中有数据长度，报头后跟数据。
TCP报头中也有4位首部长度，TCP数据也跟在紧急指针后面（有选项内容则跟在后面）
HTTP请求/响应首行，头部，空行后面跟正文
12.HTTP状态码？
HTTP状态码共分为5大类：
1打头，常见的100，服务器收到请求，请求客户端继续操作
2打头，常见的200，OK，请求成功
3打头，常见的301，永久重定向
4打头，常见的404，客户端错误，请求资源不存在。
5打头，常见的500，服务器内部错误。502 Bad GateWay，504 GateWay Time_Out
13.捎带应答和延迟应答
捎带应答：位于TCP三次握手之后的传输数据中，目的在于提升传输效率，减少不必要的确认报文。
捎带应答：目的在尽量保证窗口大小，增大网络传输的吞吐量。
14.TCP的面向字节流？
TCP传输数据是以二进制数据传送，每次去数据没有固定边界，长度不一定，可能导致粘包问题。所以在应用层将每次的传送数据进行说明将每次传输的数据大小加在TCP的报头中。
15.TCP的拥塞控制？
目的：拥塞控制是为了解决数据面临最坏情况超时重传，如果在网络固定数据大小传输中，出现网络拥堵，就会出现数据丢失。导致不断超时重传。
内容：慢开始：发送方开始拥塞窗口为1，由小到大。
快增长：每次拥塞窗口变为原来的*2,。
拥塞避免：当超过拥塞窗口大小超过阈值后，每次拥塞窗口大小+1，
快恢复：若数据丢失，接收方发送三次确认重传，发送方则将阈值降为原来的一半，重复上述操作。
16.超时重传和快重传？
超时重传：当发送方发送数据后，却迟迟没有收到确认应答。这时就可能数据丢失，发送方在等待2*RTT+偏差时间后，进行重传。
快重传：当接收端没有接收到这个数据时，后面数据包到来，就会连续发送丢失数据的序号，要求重传。
17.http0.9/1.0/1.1/2.0
0.9：只有短连接，请求只有GET请求
1.0： 默认短连接，增加长连接，增加POST，HEAD请求方法
1.1： 默认长连接，增加6种请求方法：OPTIONS，PUT，PATCH，DELETE，TRACE，CONNECT。
2.0： 服务器可以主动向客户端发送数据。
18.socket通信流程？
UDP：
客户端：建立套接字（socket）-》绑定地址信息（bind）-》收发数据（recvfrom/sendto）-》关闭套接字（close）
服务端：建立套接字-》手动绑定地址信息-》收发数据-》关闭套接字
TCP：
客户端：建立套接字（socket）-》绑定地址信息（bind）-》发送连接请求（connect）（三次握手建立连接）-》收发数据（recv/send）-》关闭套接字（close）
服务端：建立套接字（socket）-》绑定地址信息（bind）-》开始监听（监听socket）（listen）-》获取已连接的客户端新建socket（accept）-》收发数据-》断开连接关闭套接字。
19.为什么要bind，bind error如何处理?
服务端必须绑定bind，因为系统会随机分配一个可用的端口，导致客户端无法与服务端进行通信。那么客户端就无法链接。客户端不需要是因为很有可能产生冲突。
bind error：这个端口正在被占用，一个是其它进程正在占用，一个是本身端口，但没有向服务端回复最后一次分手确认。导致处于TIME_WAIT状态。服务端一直等待客户端发送ACK。断开连接中。这个时间一般持续4~5分钟。后服务端自动关闭。就可以使用
珍&源码