代码拉取完成，页面将自动刷新
同步操作将从 Thinkingcao/java-legendary 强制同步，此操作会覆盖自 Fork 仓库以来所做的任何修改，且无法恢复！！！
确定后同步将在后台操作，完成时将刷新页面，请耐心等待。
[TOC]
author：编程界的小学生
date：2021/02/23
有个经典的比喻是URI像是身份证，可以唯一标识一个人，而URL更像一个住址，可以通过URL找到这个人。
因为mac地址不具有定位功能，确切的说定位范围太小，只能在同网段被定位到，他能标志出唯一的一台物理机，但是想要找到他还需要ip来支持，一旦跨子网，就需要ip来进行通信找到具体子网，然后再根据mac定位到这个子网里的某台机器。
因为对于同一个子网上的设备，IP地址的前缀都是一样的，这样路由器通过IP地址的前缀就知道设备在在哪个子网上了，而只用MAC地址的话，路由器则需要记住每个MAC地址在哪个子网，这需要路由器有极大的存储空间，是无法实现的。
IP地址可以比作为门牌号，MAC地址为收件人的身份证，在一次通信过程中，两者是缺一不可的。
MAC地址是数据链路层和物理层使用的地址是硬件地址，IP地址网络层和以上各层使用的地址，是一种逻辑地址。在发送数据时，数据从高层到低层，然后才到通信链路上传输。使用IP地址的IP数据报一旦交给了数据链路层，就被封装成了MAC帧。MAC帧在传送时使用的源地址和目的地址都是硬件地址。
在主机 A 上运行ping 192.168.1.10后,
主机B收到后，
当一台新机器加入到一个网络的时候，他被分配IP的过程如下：
新机器会携带自己的MAC地址用IP地址0.0.0.0发送一个广播包，目的地址是255.255.255.255，广播包封装了UDP，UDP封装了BOOTP（DHCP是BOOTP的增强版）。
DHCP收到广播后，会给这个新机器分配一批IP地址（因为MAC地址是唯一的，所以DHCP知道你这个是新机器还是老机器）。
新机器收到DHCP的回复后会选择其中一个IP地址（一般是选最先达到的那个），且会向网络发送一个DHCP Request广播数据包，包含MAC地址、分配的IP地址、DHCP服务器地址等。注意这时候回复DHCP还是用0.0.0.0进行回复的，因为在未收到DHCP Server的最后确认前，客户端不能用私自选择的IP进行广播。
DHCP收到回复后会将新机器未选中作为IP的那些地址撤销，以便提供给下一个新机器用 。且会给新机器一个ack消息包。
这时候新机器就真正拥有了自己的IP地址，可以和同网段的其他机器进行通信。
以上分配的IP是租的，不是永久的，所以新机器会在租期过去 50% 的时候直接向为其提供 IP 地址的 DHCP Server 发送 DHCP request 消息包。客户机接收到该服务器回应的 DHCP ACK 消息包，会根据包中所提供的新的租期以及其他已经更新的 TCP/IP 参数，更新自己的配置。这样，IP 租用更新就完成了。
如果不租了，那么就会被DHCP回收。以便给其他机器使用。
全程通过arp协议来吼。
TCP 是面向连接的，UDP 是面向无连接的。在互通之前，面向连接的协议会先建立连接。例如，TCP 会三次握手，而 UDP 不会。
TCP 报文怎么没有源 IP 和目标 IP 呢？这是因为在 IP 层就已经处理了 IP 。TCP 只需要记录两者的端口即可。
序列号：占四个字节，在传输过程的每一个字节都会有一个编号，在建立连接后，序号就代表这一次传给对方的TCP数据部分的第一个字节的编号。
确认号：占四个字节，在建立链接后，确认号就代表期望对方下一次传过来的TCP数据部分的第一个字节的编号。
窗口：占两个字节，这个字段有流量控制功能，用以告诉对方下一次允许发送数据大小（字节为单位）。
第一次握手：Client将SYN置1，随机产生一个初始序列号seq发送给Server，进入SYN_SENT状态；
第二次握手：Server收到Client的SYN=1之后，知道客户端请求建立连接，将自己的SYN置1，ACK置1，产生一个acknowledge number=sequence number+1，并随机产生一个自己的初始序列号，发送给客户端；进入SYN_RCVD状态；
第三次握手：客户端检查acknowledge number是否为序列号+1，ACK是否为1，检查正确之后将自己的ACK置为1，产生一个acknowledge number=服务器发的序列号+1，发送给服务器；进入ESTABLISHED状态；服务器检查ACK为1和acknowledge number为序列号+1之后，也进入ESTABLISHED状态；完成三次握手，连接建立。
简单来说就是 ：
主要目的：防止server端一直等待，浪费资源。
如果建立连接只需要2次握手，可能会出现的情况：
假设client发出的第一个连接请求报文段，因为网络延迟，在连接释放以后的某个时间才到达server，本来这是一个早已失效的连接请求，但server收到此失效的请求后，误认为是client再次发出的一个新的连接请求，于是server就向client发出确认报文段，同意建立连接，如果不采用“3次握手”，那么只要server发出确认，新的连接就建立了，由于现在client并没有真正想连接服务器的意愿，因此不会理睬server的确认，也不会向server发送数据，但server却以为新的连接已经建立，并一直等待client发来数据，这样，server的很多资源就白白浪费掉了，采用 “三次握手” 的办法可以防止上述现象发生。例如上述情况，client没有向【server的确认】发出确认，server由于收不到确认，就知道client并没有要求建立连接。
四次也行 ，就是没必要，要是一直这样下去一百次都行，大于等于三次就行，浪费资源。
SYN-RCVD，若等不到client的 ACK，server会重新发送 SYN+ACK 包
服务器每收到一次客户端的请求后都会重新复位一个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
第一次挥手：Client将FIN置为1，发送一个序列号seq给Server；进入FIN_WAIT_1状态；
第二次挥手：Server收到FIN之后，发送一个ACK=1，acknowledge number=收到的序列号+1；进入CLOSE_WAIT状态。此时客户端已经没有要发送的数据了，但仍可以接受服务器发来的数据。
第三次挥手：Server将FIN置1，发送一个序列号给Client；进入LAST_ACK状态；
第四次挥手：Client收到服务器的FIN后，进入TIME_WAIT状态；接着将ACK置1，发送一个acknowledge number=序列号+1给服务器；服务器收到后，确认acknowledge number后，变为CLOSED状态，不再向客户端发送数据。客户端等待2*MSL（报文段最长寿命）时间后，也进入CLOSED状态。完成四次挥手。
TCP是全双工模式，每两次挥手都是一对的，第一二次是主机1的发送与被应答，第三四次是主机2的发送与被应答。
第1次挥手：当主机1发出FIN报文段时，表示主机1告诉主机2，主机1已经没有数据要发送了，但是，此时主机1还是可以接受来自主机2的数据
第2次挥手：当主机2返回ACK报文段时，表示主机2已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的
第3次挥手：当主机2也发送了FIN报文段时，表示主机2告诉主机1，主机2已经没有数据要发送了
第4次挥手：当主机1返回ACK报文段时，表示主机1已经知道主机2没有数据发送了。随后正式断开整个TCP连接
客户端没有收到ACK确认，会重新发送FIN请求。
[聊聊TCP的三次握手四次挥手？](# 16、聊聊TCP的三次握手四次挥手？)
主要采取的ARQ自动重传请求机制。
但是上述的ARQ协议称之为停止等待协议，太慢了！！！一个一个的发送确认，排队执行。所以有了连续ARQ协议+滑动窗口协议。
连续ARQ协议：
一次连续发送多段过去，不一个一个的发，一组一组的发，发多少合适呢？B会告诉你自己的滑动窗口是支持多大字节，然后A就不超过那么大字节就行了。
在TCP通信过程中，若发送序列中间某个数据包丢失了，比如1，2，3，4，5中的3丢失了，怎么办？
TCP会通过重传最后确认的分组后续的分组，比如确认丢失的是3，最后确认收到的数据包是2，那么会重传3，4，5。这样一来原来的4和5数据包就已经正确传输了，这次又要重传一次，没意义，降低了TCP性能。
为改善 上述情况，就出现了SACK，选择性确认技术。SACK可以明确告诉发送方丢失的3数据包， 只需要传3就行了，4和5别给我传了。
TCP是面向连接传输，三次握手四次挥手，且TCP发现失败丢包情况会自动重传，他会选择连续ARQ协议+滑动窗口协议+SACK技术来TCP传输提升性能。
因为可以提高重传的性能，具体如下：
传输层TCP具有自动重传的功能，它可以明确知道丢失的哪个数据段，然后只需要重传哪一小段就行了。
比如TCP传输一组数据到网络层，网络层给他拆分成1，2，3，4，5五个数据包发送给数据链路层，这期间数据是会丢失的，因为只有TCP带重传功能，那么数据包在往回返的时候，传输层发现数据包3丢失了，那么TCP才不知道数据包是哪个呢，因为TCP没做分层，是个整体，就会把1，2，3，4，5这一组数据包重新传给网络层。
如果接收方的缓存区满了，发送方还在一直发送数据，那么接收方只能把收到的数据包丢掉了，不仅造成了大量数据包丢失还浪费了网络资源。所以要进行流量控制。
通过确认报文中窗口字段来控制发送方的发送速率
发送方的发送窗口大小不能超过接收方给出的窗口大小
当发送方收到接收方窗口大小为0时，发送方就会停止发送数据，从而保证了流量控制。
但是有一种特殊情况：
一开始接收方给发送方发送了窗口大小为0的报文，这时候发送方肯定不会给接收方继续发消息了，一段时间后接收方空余了一些存储空间，给发送方发送的非0窗口报文段丢失了，那么发送方一直认为接收方的窗口大小为0，双方陷入了僵局。
解决方案：
因为带宽是有限的，比如带宽是100MB，但是网络请求早就大于100MB了，这时候就会造成拥塞，所以需要做拥塞控制来保证防止过多的数据注入到网络中造成丢包或网络链路过载。
有如下四种方案：
刚开始进入传输数据的时候，会发送1个MSS大小的包，然后下一次发送是2个，在下一次发送是4个，逐步递增，最终大小不会超过cwnd，这么做避免一上来就发包太猛造成疯狂丢包网络雪崩的问题。
慢启动的原理如下：
一般初始启动会按照MSS值去发，也就是最大支持的数据段大小。然后发两个MSS段，然后四个，然后八个，以此类推，阈值为3000，也就是30个。
慢启动的问题：只要慢启动cwnd达到阈值后，就不会继续增加cwnd大小了，相当于已经拥塞了 ，需要处理，所以需要拥塞避免这个手段来解决。具体流程如下图：
当达到阈值后会重新慢开始然后继续走慢启动的流程，cwnd翻倍增长。
所以拥塞避免和慢启动是配合使用的，二者为一体。
在 TCP 传输的过程中，如果发生了丢包，即接收端发现数据段不是按序到达的时候，接收端的处理是重复发送之前的 ACK。
比如M3包丢了，即使M4、M5包到达的接收端，接收端也一律返回第M2个包的 ACK。当发送端收到3个重复的 ACK 时，意识到丢包了，于是马上进行重传M3，不用等到一个RTO的时间到了才重传。
这就是快速重传，它解决的是是否需要重传的问题。
发送端收到三次重复 ACK 之后，发现丢包，他会觉得现在的网络已经有些拥塞了，自己会进入快速恢复阶段。
在这个阶段，发送端如下改变：
快速重传配合快速恢复的图示如下：
短连接就是一次TCP请求得到结果后连接马上结束。
长连接并不马上断开，而一直保持着,直到长连接TIMEOUT，长连接可以避免不断的进行TCP三次握手和四次挥手。
长连接(keepalive)是需要靠双方不断的发送探测包来维持的,keepalive期间服务端和客户端的TCP连接状态是ESTABLISHED。
**socket连接是长连接。**网络上的两个程序通过一个双向的通讯连接实现数据的交换，这个双向链路的一端称为一个Socket。Socket通常用来实现客户方和服务方的连接。Socket是TCP/IP协议的一个十分流行的编程界面，一个Socket由一个IP地址和一个端口号唯一确定。
基于TCP：服务器端先初始化Socket，然后与端口绑定(bind)，对端口进行监听(listen)，调用accept阻塞，等待客户端连接。在这时如果有个客户端初始化一个Socket，然后连接服务器(connect)，如果连接成功，这时客户端与服务器端的连接就建立了。客户端发送数据请求，服务器端接收请求并处理请求，然后把回应数据发送给客户端，客户端读取数据，最后关闭连接，一次交互结束。
基于UDP：UDP 协议是用户数据报协议的简称，也用于网络数据的传输。虽然 UDP 协议是一种不太可靠的协议，但有时在需要较快地接收数据并且可以忍受较小错误的情况下，UDP 就会表现出更大的优势。我客户端只需要发送，服务端能不能接收的到我不管。
DNS用于将域名解析成IP。用的是UDP协议，端口53。是个树形结构，分为如下三层：
解析过程
CDN的核心是就近访问，降低网络拥塞，提高用户访问速度。比较适合存储静态资源（比如css js 静态html等）来加速。
短连接：客户端和服务器每进行一次HTTP操作就建立一次连接，一次请求结束后就中断连接。
长连接：客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接，有一个保持时间。
HTTP/1.1 200 OK。
大多情况下GET用于获取资源，所以是具有幂等性的，POST用于修改资源，不具有幂等性
GET将参数放到url后面拼接，POST将请求参数放到body中
GET请求参数有大小限制，最多2048字节，POST没限制
GET请求不安全，因为参数暴露到url后面了，POST相对安全
对称加密：对称加密指加密和解密使用同一密钥，优点是运算速度快，缺点是如何安全将密钥传输给另一方。常见的对称加密算法有DES、AES等等。
非对称加密：非对称加密指的是加密和解密使用不同的密钥，一把公开的公钥，一把私有的私钥。公钥加密的信息只有私钥才能解密，私钥加密的信息只有公钥才能解密。优点解决了对称加密中存在的问题。缺点是运算速度较慢。常见的非对称加密算法有RSA、DSA、ECC等等。
非对称加密的工作流程：A生成一对非堆成密钥，将公钥向所有人公开，B拿到A的公钥后使用A的公钥对信息加密后发送给A，经过加密的信息只有A手中的私钥能解密。这样B可以通过这种方式将自己的公钥加密后发送给A，两方建立起通信，可以通过对方的公钥加密要发送的信息，接收方用自己的私钥解密信息。
| HTTP | HTTPS | |
|---|---|---|
| 端口 | 80 | 443 |
| 安全性 | 无加密，安全性较差 | 有加密机制，安全性较高 |
| 资源消耗 | 较少 | 由于加密处理，资源消耗更多 |
| 是否需要证书 | 不需要 | 需要 |
| 协议 | 运行在TCP协议之上 | 运行在SSL协议之上，SSL运行在TCP协议之上 |
HTTPS使用的对称加密和非对称加密的混合加密算法。具体做法就是使用非对称加密来传输对称密钥来保证安全性，使用对称加密来保证通信的效率。
HTTPS的加密过程：
HTTP 1.0和HTTP 1.1的区别
HTTP 1.1支持长连接，HTTP 1.0默认使用短连接。
在HTTP 1.1新增了24个错误状态响应码
在HTTP 1.0 中认为每台服务器都会绑定唯一的IP地址，所以，请求中的URL并没有传递主机名。但后来一台服务器上可能存在多个虚拟机，它们共享一个IP地址，所以HTTP 1.1中请求消息和响应消息都应该支持Host域。
HTTP1.1 支持只发送 header 而不发送 body。原因是先用 header 判断能否成功，再发数据，节约带宽，事实上，post 请求默认就是这样做的。
HTTP2.0 的主要变化
HTTP2.0 支持多路复用，同一个连接可以并发处理多个请求，方法是把 HTTP数据包拆为多个帧，并发有序的发送，根据序号在另一端进行重组，而不需要一个个 HTTP请求顺序到达；
HTTP2.0 支持服务端推送，就是服务端在 HTTP 请求到达后，除了返回数据之外，还推送了额外的内容给客户端；
HTTP2.0 压缩了请求头，同时基本单位是二进制帧流，这样的数据占用空间更少；
HTTP2.0 适用于 HTTPS 场景，因为其在 HTTP和 TCP 中间加了一层 SSL 层。
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。