计算机网络五层协议
应用层
应用层协议定义的是应用进程（进程：主机中正在运行的程序）间的通信和交互的规则，即数据解读格式，对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如域名系统DNS，支持万维网应用的 HTTP协议，支持电子邮件的 SMTP协议，此外还有FTP、Telnet、POP3等等。我们把应用层交互的数据单元称为报文。
运输层
负责向两台主机进程之间的通信提供通用的端到端传输服务，使得应用进程可以传输应用层报文，通用是指多个应用可以使用同一个运输层服务。
运输层主要使用以下两种协议:
传输控制协议 TCP（Transmission Control Protocol）--提供面向连接的，可靠的数据传输服务。
用户数据协议 UDP（User Datagram Protocol）--提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性）
网络层
择合适的网间路由和交换结点，通过IP协议传输数据包 。通过优先权、网络拥塞和服务质量及花费来选择最佳路由路径。实现数据包主机到主机的传输。
数据链路层
数据链路层将网络层交下来的 IP 数据报组装程帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）
物理层
实现相邻计算机节点之间比特流的透明传送。通俗说就是把计算机连接起来的物理手段。
该协议体系中，下层会依次把上层数据封装，加上特定的协议信息
TCP 协议中的三次握手
客户端–发送带有 SYN 标志的数据包,并携带seq序列号，客户端进入SYN-SENT状态
服务端–发送带有 SYN/ACK 标志的数据包，并携带ack字段，其值为收到的seq序列号+1,此外还携带一个新的seq序列号，此时服务端进入SYN_RCVD状态
客户端–发送带有带有 ACK 标志的数据包，并携带ack字段为刚收到的seq序列号+1，此时客户端进入ESTABLISHED状态，当服务器也收到客户端的返回报文时也进入了ESTABLISHED状态。
大写的ACK表示一次通信报文的标志位，小写的ack表示对上次seq序列号的应答
为什么要三次握手
三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。
客户端和服务端发送报文时会各自携带一个seq序列号，这个序列号在不断地发送中会递增，用于标识报文和对报文传递状态进行跟踪，如果丢包需要执行重传逻辑。三次握手是保证客户端和服务端能够确保自身发出的报文能够被正常接收的最小次数。
SYN洪泛攻击
黑客通过伪造大量的虚假IP给服务器发送TCP连接请求，服务器返回请求后等待客户端response，但由于是虚假IP所以不会有应答，造成服务器资源被耗尽在等待回复上。
解决方案一般有三种：
- 防火墙（确认真实连接有效之后才向服务器发送SYN请求）
- 无效连接监控释放
- 延缓TCB分配方法
TCP协议中的四次挥手
- 客户端-发送一个 FIN，用来关闭客户端到服务器的数据传送
- 服务器-收到这个 FIN，它发回一 个 ack，确认序号为收到的序号加1 。和 SYN 一样，一个 FIN 将占用一个序号
- 服务器-关闭与客户端的连接，发送一个FIN给客户端
- 客户端-发回 ack 报文确认，并将确认序号设置为收到序号加1
为什么要四次挥手
任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。
举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。
https://blog.csdn.net/qzcsu/article/details/72861891
TCP 和 UDP 区别
TCP 面向有连接的服务， 不提供广播或多播服务。是提供可靠的，面向连接的传输服务。体现在传输之前发送方和接收方必须要先通过三次握手建立连接，为了保证传输的可靠性，有确认，窗口、重传、拥塞控制，在数据传输完成后，才断开连接来节约系统资源。这会增加很多开销，如确认、流量控制、计时器和连接管理等，还使得数据首部增大很多，占用额外处理机资源，基于以上，TCP的速率较低。所以TCP协议一般用于文件传输，收发邮件和远程登录等场景。
UDP 面向无连接的服务，在传输前不需要建立连接，接收方也不需要发回任何确认信息，UDP传输速率仅仅受数据的速度，计算机的能力和传输带宽的限制，纵然有不可靠的缺陷，但其更高的速率和较低的资源占用使得某些场景下更实用，如QQ语音、QQ视频、直播等。
TCP如何保证数据传输可靠
1、应用数据被分割成 TCP 认为最适合发送的数据块。
2、TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
3、校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
4、TCP 的接收端会丢弃重复的数据。
5、流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制）
6、拥塞控制： 当网络拥塞时，减少数据的发送。
7、ARQ协议： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
8、超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
在浏览器中输入url地址 ->> 显示主页的过程
1、通过DNS解析IP地址
2、建立TCP链接
3、发送Http请求
4、服务器收到请求并返回http报文
5、浏览器解析渲染界面
6、连接结束
- https://segmentfault.com/a/1190000006879700
一图了解网络请求过程
HTTP协议解析
请求报文
包括请求行、请求报头、空行、请求数据4部分构成
请求行包括：Method、Request-URI、Http_Version CRLF
常用的method就是GET和POST， 包括HEAD,PUT,DELETE,TRACE,CONNECT,OPTIONS等。
响应报文
包括状态行、响应报头、空行、响应正文组成。
状态行包括：Http_Version,Status_Code, Reason-Phrase CRLF
常见的响应状态码有200客户端请求成功，400客户端请求语法有误，401请求未经授权，403服务器收到请求但是拒绝提供服务，500 服务器内部错误、503 服务器当前不能处理客户端的请求。
响应状态码分类：
100-199 提示信息，收到请求，需要请求者进一步操作
200-299 请求成功，已经成功处理
300-399 重定向 完成请求必须进一步操作
400-499 客户端错误，语法错误或者请求无法实现
500-599 服务端错误，服务器不能shi先合法的要求
Http的消息报头
有通用报头、请求报头、响应报头和实体报头等，通常由键值对组成，由 : 分隔
HTTP连接中如何保存用户的状态
http是无状态(stateless)额协议，不能保存用户和服务器交互的状态。完成请求后，服务器如何知道将数据返回给正确的客户端呢？
Session
用于保存客户端和服务器交互的状态，session信息保存途径很多，一般保存在服务器中，有时间限制，超过时限后该session失效。
典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。
通常服务器通过sessionID标记特定的客户端，我们通过在cookie中附加一个sessionID来跟踪客户端，如果cookie被禁用了，就通过附加到URL后来进行访问。
Cookie
用于保存用户登录的基本信息，如用户名和密码等等，这样就不用再下次登录网站的时候再输入一次信息。Cookie通常保存在客户端，安全性较差，访问网站的时候存放一个token在Cookie中，下次登录时候查询该token即可。
Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更高。如果使用 Cookie 的一些敏感信息不要写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。
URI和URL的区别是什么
URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
URL(Uniform Resource Location) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。
HTTP 和 HTTPS 的区别
端口 ：HTTP的URL由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443。
安全性和资源消耗： HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL(Secure Sockets Layer)/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。此外，SEO方面，谷歌搜索引擎算法对https网页偏爱，“同等”网站在搜索结果排名中更高；HTTPS需要用到SSL证书，而HTTP不用；
对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；
非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。
为什么不是所有网站都使用https
既然HTTPS那么安全可靠，那为何不所有的Web网站都使用HTTPS？
首先，很多人还是会觉得HTTPS实施有门槛，这个门槛在于需要权威CA颁发的SSL证书。从证书的选择、购买到部
署，传统的模式下都会比较耗时耗力。
其次，HTTPS普遍认为性能消耗要大于HTTP，因为与纯文本通信相比，加密通信会消耗更多的CPU及内存资源。如果
每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。但事实并
非如此，用户可以通过性能优化、把证书部署在SLB或CDN，来解决此问题。举个实际的例子，“双十一”期间，全站
HTTPS的淘宝、天猫依然保证了网站和移动端的访问、浏览、交易等操作的顺畅、平滑。通过测试发现，经过优化后
的许多页面性能与HTTP持平甚至还有小幅提升，因此HTTPS经过优化之后其实并不慢。
除此之外，想要节约购买证书的开销也是原因之一。要进行HTTPS通信，证书是必不可少的。而使用的证书必须向认
证机构（CA）购买。
参考：
- https://juejin.im/entry/58d7635e5c497d0057fae036
- https://blog.csdn.net/qq_16209077/article/details/52718250
- https://blog.csdn.net/zixiaomuwu/article/details/60965466
- https://blog.csdn.net/turn__back/article/details/73743641
- https://mp.weixin.qq.com/s/GICbiyJpINrHZ41u_4zT-A?