网络模型
七层模型：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层
应用层： 网络服务与最终用户的一个接口。
协议有：HTTP FTP TFTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP
表示层 ：数据的表示、安全、压缩。 格式有：JPEG、ASCll、EBCDIC、加密格式等
会话层 ：建立、管理、终止会话。
传输层：定义传输数据的协议端口号，以及流控和差错校验。 协议有：TCP UDP。
网络层 ：进行逻辑地址寻址，实现不同网络之间的路径选择。 协议有：ICMP IGMP IP
数据链路层： 建立逻辑连接、进行硬件地址寻址、差错校验等功能。（由底层网络定义协议） 将比特组合成字节进而组合成帧，用MAC地址访问介质，错误发现但不能纠正。
物理层 ：建立、维护、断开物理连接。
TCP/IP 层级模型结构，之间的协议通过逐级调用[传输层]网络层 和物理[数据链路层]
可以实现应用层的应用程序通信互联。 应用层需要关心应用程序的逻辑细节，而不是数据在网络中的传输活动。应用层其下三层则处理真正的通信细节。
http协议报文：请求报文(请求行/请求头/请求数据/空行) http 有哪些部分?
1.请求行：请求方式，URL字段和HTTP协议版本 例如：GET /index.html HTTP/1.1
请求方法： GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT
1.1 ：get方法将数据拼接在url后面，传递参数受限 ，不安全
1.2： post方法中，会把数据以key value形式发送请求，放在请求体中。
2. 请求头(key value形式)
User-Agent：产生请求的浏览器类型。
Accept：客户端可识别的内容类型列表。
Host：主机地址
3. 响应报文(状态行、消息报头、响应正文) 状态行 消息报头 响应正文
get和post的区别？
1. get一般用于从服务器上获取数据，post一般用于向服务器传输数据
2. get采用的地址传参，传输的数据量小，一般2K；post采用报文传参, 可传输的数据量很大，一般默认无限传输，但实际有上限(4G)
3. get安全性非常低，post安全性较高
4. get不能上传文件，post可以上传文件
TCP、IP头部多长?
IP: 头部范围为20B(不含options)~60B
UDP: 头部长度是固定的，为12B(假头部)+8B(真头部) = 20B
TCP: 跟IP头长度一样，20B~60B，取决于有没有options.
TCP是如何保证可靠的？
1：确认和重传：接收方收到报文就会确认回执，发送方发送一段时间后没有收到确认就重传。
2：数据校验
3：数据合理分片和排序：
UDP：IP数据报大于1500字节,大于MTU.这个时候发送方IP层就需要分片(fragmentation).把数据报分成若干片,使每一片都小于MTU.而接收方IP层则需要进行数据报的重组。由于UDP的特性,当某一片数据传送中丢失时，接收方便无法重组数据报。UDP会判断报文是否完整，不完整就不做处理，丢弃整个UDP数据报。
TCP: 会按MTU合理分片，接收方会缓存未按序到达的数据，重新排序后再交给应用层。
4：流量控制：当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。（通过滑动窗口大小的调整来进行流量控制，根据宽带大小，链路是否拥塞，接收方能处理的数据量来进行动态调整。）
5：拥塞控制：当网络拥塞时，减少数据的发送。
4. TCP粘包/UDP窜包？
粘包和窜包都很简单，通过设置包头和序列号基本上就可以解决相应的问题，这里仅简单提一下。所谓的TCP粘包是在一次接收数据不能完全地体现一个完整的消息数据。
TCP通讯为何存在粘包呢？主要原因是TCP是以流的方式来处理数据，再加上网络上MTU的往往小于在应用处理的消息数据，所以就会引发一次接收的数据无法满足消息的需要，导致粘包的存在。
处理粘包的唯一方法就是制定应用层的数据通讯协议，通过协议来规范现有接收的数据是否满足消息数据的需要。
在应用中处理粘包的基础方法主要有两种：分别是以4节字描述消息大小或制定 结束符，实际上也有两者相结合的如HTTP,redis的通讯协议等。
TCP --4次挥手流程：
MTU的理解？
最大输出单元，如果在IP层要传输一个数据报比链路层的MTU还大，那么IP层就会对这个数据报进行分片。一个数据报会被分为若干片，每个分片的大小都小于或者等于链路层的MTU值。当同一网络上的主机互相进行通信时，该网络的MTU对通信双方非常重要。
HTTP和HTTPS区别？
① https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用；http一般是免费的。
② http是超文本传输协议，信息是明文传输；https则是具有安全性的ssl加密传输协议。
③ http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
④ http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
HTTPS 中的 SSL 握手建立过程
1：首先，客户端 A 访问服务器 B。客户端 A 会生成一个随机数1，把随机数1 、自己支持的 SSL 版本号以及加密算法等这些信息告诉服务器 B 。
2：服务器 B 知道这些信息后，确认一下双方的加密算法，然后服务端也生成一个随机数 B ，并将随机数 B 和 CA 颁发给自己的证书一同返回给客户端 A 。
3：客户端 A 得到 CA 证书后，校验该 CA 证书的有效性。校验通过后，客户端生成一个随机数3 ，然后用证书中的公钥加密随机数3 并传输给服务端 B 。服务端 B 得到加密后的随机数3，然后利用私钥进行解密，得到真正的随机数3。
4：客户端 A 和服务端 B 都有随机数1、随机数2、随机数3，然后双方利用这三个随机数生成一个对话密钥。之后传输内容就是利用对话密钥来进行加解密了。这时就是利用了对称加密，一般用的都是 AES 算法。
5：客户端 A 通知服务端 B ，指明后面的通讯用对话密钥来完成，同时通知服务器 B 客户端 A 的握手过程结束。
6：服务端 B 通知客户端 A，指明后面的通讯用对话密钥来完成，同时通知客户端 A 服务器 B 的握手过程结束。SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户端 A 和服务器 B 开始使用相同的对话密钥进行数据通讯。
简单地来讲：
客户端和服务端建立 SSL 握手：客户端通过 CA 证书来确认服务端的身份；互相传递三个随机数，之后通过这随机数来生成一个密钥；互相确认密钥，然后握手结束；数据通讯开始，都使用同一个对话密钥来加解密；
在 HTTPS 加密原理的过程中把对称加密和非对称加密都利用了起来。即利用了非对称加密安全性高的特点，又利用了对称加密速度快，效率高的好处。
中间人攻击
中间人攻击（英语：Man-in-the-middle attack，缩写：MITM），指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。
中间人攻击过程
1、截获客户端与服务器通信的通道
2、然后在 SSL 建立连接的时候，进行中间人攻击
3、将自己伪装成客户端，获取到服务器真实有效的 CA 证书（非对称加密的公钥）
4、将自己伪装成服务器，获取到客服端的之后通信的密钥（对称加密的密钥）
5、有了证书和密钥就可以监听之后通信的内容了
charles抓包原理
抓取https包的时候,青花瓷会要求使用设备对抓包的设备, 安装一个证书,安装这个证书的时候,其实是安装了一个根证书(允许颁发CA的一个证书机构的根证书), 安装了该根证书之后,该证书机构颁发的其他证书, 默认都会被你的系统所信任,这个就是青花瓷完成https抓包的一个重要前提!!
1：当客户端对服务器Server发送请求(带着随机数和加密算法), 青花瓷做了代理,请求被青花瓷拦截处理。
注意：青花瓷收到客户端的随机数和加密算法, 自己生成一对密钥，选择一个客户端的加密算法。
2：青花瓷伪装成客户端去请求Server。Server会和青花瓷完成证书校验, 并且读取青花瓷带来的具体请求, 返回正常的数据结果。
3：青花瓷得到服务器数据的返回结果后, 伪装成服务器的身份去和客户端通信
青花瓷生成的公钥和真实的server不一样, 但是域名是一样的, 除了域名是一致的,其他的都不是一致的。这个签发机构是青花瓷之前让安装的根证书签发的。所以当返回这个证书的时候,客户端设备的验证是通过的。
青花瓷会返回一个伪造的CA证书。Client用这个伪造的证书,和青花瓷通信。然后青花瓷再和Server通信。成了一个中间人的角色,这样,整个过程的数据传输,都被青花瓷给监听到了
常见面试题
【问题1】为什么连接的时候是三次握手，关闭的时候却是四次握手？
答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。
【问题3】为什么不能用两次握手进行连接？
答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
【问题4】如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
参考：
Https原理及流程 - 客户端&服务器建立SSL连接的效验过程
对称加密、非对称加密、数字签名 -
TCP/IP协议简单总结_等待化茧成蝶的专栏-CSDN博客 7层网络协议每一层特点
TCP 3次握手，4次挥手状态详解
https://blog.csdn.net/qq_42447950/article/details/81329900 3次握手 和 4次挥手 && tcp 和 udp 的区别 ，TCP 内部的字段和意思，讲解易懂
TCP粘包，拆包及解决方法 - panchanggui - 博客园
客户端认证服务端证书的过程_zxr的博客-CSDN博客
Http与Socket的介绍以及两者之间的区别_等待化茧成蝶的专栏-CSDN博客
http 请求包含哪几个部分（请求行、请求头、请求体） - 码农教程
https://blog.csdn.net/whuslei/article/details/6667471 里面有一些配图，可以看一下，和上面的类似
https://blog.csdn.net/qq_38950316/article/details/81087809 3次握手 和 4次挥手 ，面试题相关
TCP长连接与短连接的区别 - 后端技术 - 博客园
https://blog.csdn.net/luo_boke/article/details/114220450 ssl 和 tls 区别