关于HTTP相关协议的一些总结

发表于 2022-09-05

粗浅概括

HTTP - TCP
HTTPS - TCP + TLS
SPDY -> TCP + TLS + 多路复用、头部压缩等特性 –> 发展成 HTTP/2
- SPDY是Speedy的音，是更快的意思
HTTP/2 - TCP + TLS(理论上可选) + 多路复用、头部压缩等特性
QUIC - UDP –> 发展成 HTTP/3
HTTP/3 - UDP

其他基础

RTT(Round-Trip Time): 往返时延。在计算机网络中它是一个重要的性能指标，表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。

HTTP

请求-响应模式（半双工）

安全问题

“队头堵塞” （线头阻塞）（Head-of-line blocking）（HOLB）

HTTP 1.1 默认启用长TCP连接，但所有的请求-响应都是按序进行的(串行发送和接收)
HTTP 1.1 的管道机制：客户端可以同时发送多个请求，但服务端也需要按请求的顺序依次给出响应的；
客户端在未收到之前所发出所有请求的响应之前，将会阻塞后面的请求(排队等待)，这称为”队头堵塞”

管道机制(Pipelining)

在管道机制下，服务端如何控制按顺序返回响应的？
- HTTP是应用层协议，当然由各个应用程序按照规范自行实现了
- 比如使用nginx，或jetty等，若服务端需要支持管道机制，都要底层逻辑自行实现，避免暴露给业务层
- 那么因为要按顺序响应，那么当最前的请求的处理较慢时，同样会对服务端产生阻塞。
Pipelining需要客户端和服务端同时支持
几乎所有的浏览器都是默认关闭或者不支持Pipelining的：对性能的提高有限、大文件会阻塞优先级更高的小文件等
只有GET和HEAD要求可以进行管线化，而POST则有所限制

HTTPS

HTTPS（HTTP over TLS/SSL）,TLS/SSL(会话层)
SSL（Secure Socket Layer）是安全套接层，TLS（Transport Layer Security）是传输层安全协议，建立在SSL3.0协议规范，是 SSL3.0 的后续版本。
TLS可以用在TCP上，也可以用在无连接的UDP报文上。协议规定了身份认证、算法协商、密钥交换等的实现。
SSL是TLS的前身，现在已不再更新

jks、pfx和cer 证书文件

jks是JAVA的keytools证书工具支持的证书私钥格式。
pfx是微软支持的私钥格式。
cer是证书的公钥。

权威证书颁发的公钥匙一般是预装的

SSL/TLS协议详解(中)——证书颁发机构
当我们安装浏览器或操作系统时，将会附有一组证书颁发机构，例如DigiCert。当浏览器自带DigiCert时，这意味着浏览器具有DigiCert的公钥，网站可以向DigiCert索取证书和签名。因此，DigiCert将使用DigiCerts私钥在服务器证书上进行加密签名。当我们发起连接时，服务器将发送嵌入了其公钥的证书。由于浏览器具有DigiCert的公钥，因此可以在服务器证书上验证DigiCert的签名，同时也说明证书上写的服务器的公钥是可信的。
根据RSA的加密原理，如果用CA的公钥解密成功，说明该证书的确是用CA的私钥加密的，可以认为被验证方是可信的。

HTTP/2

全双工
二进制格式传输、多路复用、header压缩、服务端推送、优先级和依赖关系、重置、流量控制

多路复用(Multiplexing)

客户端发送多个请求和服务端给出多个响应的顺序不受限制, 避免”队头堵塞”
每个数据流都有一个唯一的编号，从而让请求和响应对应起来
客户端和服务器可以发生信号取消某个数据流，并保持这个连接
客户端还可以提升提升某个数据流优先级

加密

HTTP/2 沒规定一定要使用加密（例如 SSL），但目前大部分浏览器的 HTTP/2 都需要在 HTTPs上运行
gRPC 虽然使用 HTTP/2，但默认并没有需要配置加密证书

重用连接（针对浏览器）

使用HTTP1.1协议，浏览器为了快速，针对同一域名设置了一定的并发数，稍微加快速度
使用HTTP/2，浏览器针对同一个域名的资源，只建立一个tcp连接通道

头部压缩

头部压缩也存在一些缺点，不管是Client还是Server，都要维护索引表，以确定每个索引值对应HTTP header的信息，通过占用更多内存换取数据量传输的减少（空间换时间）。

推送

Chrome将禁用HTTP/2服务器推送（Server Push）支持
- 这功能逻辑本身就有问题，比如资源存放在单个业务服务器上，并行推送多个静态资源只会降低响应速度，性能不升反降。而对于前后端分离的业务来说，HTTP/2 本身就支持多路复用，server push 只能稍微降低浏览器解析 html 的时间，对现代浏览器来说性能提升可以忽略不计。

HTTP/3

HTTP/1.x 有连接无法复用、队头阻塞、协议开销大和安全因素等多个缺陷
HTTP/2 通过多路复用、二进制流、Header 压缩等等技术，极大地提高了性能，但是还是存在着问题的
QUIC 基于 UDP 实现，是 HTTP/3 中的底层支撑协议，该协议基于 UDP，又取了 TCP 中的精华，实现了即快又可靠的协议
HTTP3.0，也称作HTTP over QUIC。HTTP3.0的核心是QUIC(读音quick)协议，由Google在2015年提出的SPDY v3演化而来的新协议，传统的HTTP协议是基于传输层TCP的协议，而QUIC是基于传输层UDP上的协议，可以定义成：HTTP3.0基于UDP的安全可靠的HTTP2.0协议。
在网络条件较差的情况下，HTTP/3在增强网页浏览体验方面的效果非常好
TCP从来就不适合处理有损无线环境中的数据传输
TCP中的行头阻塞

TCP的限制

TCP可能会间歇性地挂起数据传输
- TCP流的行头阻塞（HoL）: 序列号较低的数据段丢包问题，导致阻塞
TCP不支持流级复用
TCP会产生冗余通信
- TCP连接握手会有冗余的消息交换序列，即使是与已知主机建立的连接也是如此。

新特性

选择UDP作为底层传输层协议。抛弃TCP的缺点（TCP传输确认、重传慢启动等），同时。此外QUIC是用户层协议，不需要每次协议升级时修改内核；
流复用和流控：解决了行头阻塞问题。
灵活的拥塞控制机制、更好的错误处理能力、更快的握手
新的HTTP头压缩机制，称为QPACK，是对HTTP/2中使用的HPACK的增强（QUIC流是不按顺序传递的，在不同的流中可能包含不同的HTTP头）

采用HTTP/3的限制

不仅涉及到应用层的变化，还涉及到底层传输层的变化
UDP会话会被防火墙的默认数据包过滤策略所影响
中间层，如防火墙、代理、NAT设备等需要兼容
需迫使中间层厂商标准化
HTTP/3在现有的UDP之上，以QUIC的形式在传输层处理，增加了HTTP/3在整个协议栈中的占用空间。这使得HTTP/3较为笨重，不适合某些IoT设备
NGINX和Apache等主流web服务器需要支持

Q&A

HTTP 与 TCP backlog关系

没直接关系
HTTP是应用层协议，TCP backlog 是应用程序在操作系统层接收tcp连接的队列数
比如tomcat，作为一个HTTP应用服务，TCP backlog对应其acceptCount的配置

关于 HTTP keepalive

要利用HTTP的keep-alive机制，需要服务器端和客户端同时支持
HTTP是应用层协议，具体的表现行为取决于HTTP服务器以及HTTP client的实现
wireshark抓包简单查看HTTP keep-alive原理
继续深入理解HTTP keepalive

keepalive 是否开启服务端控制还是客户端控制？
- keepalive可以由双方共同控制，需要双方都开启才能生效，HTTP1.1客户端默认开启，客户端想关闭可以通过设置Connection: Close，服务端同样想关闭可以设置Connection: Close。双方哪方先收到Connection: Close 则由收到方关闭（前提是双方的实现都支持，比如telnet就不支持）
keepalive的时间是由服务端控制还是客户端控制？
- 时间主要还是由服务端控制，时间一到由服务端主动关闭，当然客户端如果有实现设置一定时间后，由客户端主动关闭也可以。一般的HTTPclient库都有提供相应的配置，设置关闭长期不使用的连接，如connectionManager.closeIdleConnections(readTimeout * 2, TimeUnit.MILLISECONDS);
- HTTPs://my.oschina.net/greki/blog/83350
keepalive时间一到，是由客户端主动关闭还是服务端主动关闭？
- 哪方的时间短，由哪一方来关闭，除非双方的实现有更明确的协议
如果客户端不是HTTPclient，使用telnet连接服务端？
- telnet客户端除了连接时进行三次握手，用来发送数据接收数据，基本无其他实现逻辑。即接收到服务器的响应之后，不会有相关HTTP协议的处理。

HTTP keepalive VS TCP keepalive

HTTPs://zhuanlan.zhihu.com/p/385597183; HTTPs://juejin.cn/post/6992845852192702477
HTTP 的 Keep-Alive，是由应用层（用户态）实现的，称为 HTTP 长连接；
TCP 的 Keepalive，是由 TCP 层（内核态）实现的，称为 TCP 保活机制；
HTTP协议的Keep-Alive意图在于短时间内连接复用，希望可以短时间内在同一个连接上进行多次请求/响应。
TCP的KeepAlive机制意图在于保活、心跳，检测连接错误。当一个TCP连接两端长时间没有数据传输时(通常默认配置是2小时)，发送keepalive探针，探测链接是否存活。
tcp的keepalive是在ESTABLISH状态的时候，双方如何检测连接的可用行。而HTTP的keep-alive说的是如何避免进行重复的TCP三次握手和四次挥手的环节。
总之，HTTP的Keep-Alive和TCP的KeepAlive不是一回事。

Chrome中HTTP下载续传原理

Chrome下载文件时暂停和继续是什么原理？

HTTP连接复用时，同一个连接上的多个请求和响应如何对应上？

“队头堵塞”（Head-of-line blocking）：所有的请求-响应都是按序进行的（HTTP）
多路复用(Multiplexing)：每个数据流都有一个唯一的编号，从而让请求和响应对应起来（HTTP/2）

可以外网使用HTTP/3，再转发到内网的HTTP服务？

上层nginx使用HTTP3，下层应用服务器（如spring boot jetty等）还是使用HTTP，其实理论上是可以的。nginx转发时要由接受到的udp包改成tcp发送。（内网丢包概率一般应该比外网丢包低很多），如果采用这种转发方式，这就意味着内网无法使用四层负载转发，因为底层协议不一样（udp和tcp）
现在主流的代理服务Nginx/Apache都没有实现QUIC，一些比较小众的代理服务如Caddy就实现了

使用HTTPS还存在中间人攻击？

结论：可以避免。只要不信任不安全的HTTPs网站，就不会被中间人攻击
中间人攻击:HTTPs://urlify.cn/zQj6f2
既然证书是公开的，如果要发起中间人攻击，我在官网上下载一份证书作为我的服务器证书，那客户端肯定会认同这个证书是合法的，如何避免这种证书冒用的情况？
其实这就是非加密对称中公私钥的用处，虽然中间人可以得到证书，但私钥是无法获取的，一份公钥是不可能推算出其对应的私钥，中间人即使拿到证书也无法伪装成合法服务端，因为无法对客户端传入的加密数据进行解密。
只要客户端是我们自己的终端，我们授权的情况下，便可以组建中间人网络，而抓包工具便是作为中间人的代理。

Q: 为什么需要证书？
A: 防止”中间人“攻击，同时可以为网站提供身份证明。

Q: 使用 HTTPS 会被抓包吗？
A: 会被抓包，HTTPS 只防止用户在不知情的情况下通信被监听，如果用户主动授信，是可以构建“中间人”网络，代理软件可以对传输内容进行解密。

扩展

cURL 发 HTTP/2请求

Mac OS Curl HTTP/2 支持
brew install curl --with-ngHTTP2

/usr/local/Cellar/curl/7.50.3/bin/curl --HTTP2 -kI  HTTPs://localhost:8443/user/1
HTTP/2 200
server: Jetty(9.3.10.v20160621)
date: Sun, 30 Oct 2016 02:08:46 GMT
content-type: application/json;charset=UTF-8
content-length: 23

linux:HTTPs://www.sysgeek.cn/curl-with-HTTP2-support/

HTTP/3 握手优化

1倍时延 = 一次单向传输时延 = 0.5 RTT
HTTPS 的 7 次握手以及 9 倍时延

HTTPS: 7 次握手以及 9 倍时延 (4.5 RTT); HTTP/3: 3 次握手以及 5 倍时延 (2.5 RTT)

当客户端想要通过 HTTPS 请求访问服务端时，整个过程需要经过 7 次握手并消耗 9 倍的延迟。如果客户端和服务端因为物理距离上的限制，RTT 约为 40ms 时，第一次请求需要 ~180ms；不过如果我们想要访问美国的服务器，RTT 约为 200ms 时，这时 HTTPS 请求的耗时为 ~900ms，这就是一个比较高的耗时了。我们来总结一下 HTTPS 协议需要 9 倍时延才能完成通信的原因：

TCP 协议需要通过三次握手建立 TCP 连接保证通信的可靠性（1.5-RTT）；
TLS 协议会在 TCP 协议之上通过四次握手建立 TLS 连接保证通信的安全性（2-RTT）；
HTTP 协议会在 TCP 和 TLS 上通过一次往返发送请求并接收响应（1-RTT）；
需要注意的是，本文对往返延时的计算都基于特定的场景以及特定的协议版本，网络协议的版本在不断更新和演进，过去忽略的问题最开始都会通过补丁的方式更新，但是最后仍然会需要从底层完成重写。

HTTP/3 就是一个这样的例子，它会使用基于 UDP 的 QUIC 协议进行握手，将 TCP 和 TLS 的握手过程结合起来，把 7 次握手减少到了 3 次握手，直接建立了可靠并且安全的传输通道，将原本 ~900ms 的耗时降低至 ~500ms，

Reference

Chrome下载文件时暂停和继续是什么原理？

发表于 2022-08-30

这个问题很久前就研究过了，觉得挺有意思，这里总结记录一下
所有的文字整理来源于: https://bbs.csdn.net/topics/392163074,感谢wjyiooo的耐心解答

Range

Range，是在 HTTP/1.1（http://www.w3.org/Protocols/rfc2616/rfc2616.html）里新增的一个 header field，也是现在众多号称多线程下载工具（如 FlashGet、迅雷等）实现多线程下载的核心所在。

chrome 版本58

抓包确认，chrome点击暂停的时候会发送一系列窗口变动应答，将窗口降到5，并且不再应答ACK包。当点击恢复的时候只是重新发送ACK给服务器，同时将窗口重新设置为256。
以上可以确认它的“续传”只是利用TCP滑动窗口的特性，跟断不断网没关系，也不属于真正意义的断点续传功能（一般用range头部实现）。当然如果你中断网络超过了服务器的TCP连接超时时间那么就不能续传了，而且如果关闭浏览器即使网络非常正常也不能续传（也是因为TCP连接断了）。
在等待足够长时间让TCP连接关掉后，chrome就可以断点续传了，原理也是头部带range。

总结

本地有临时下载文件
短时间内点继续，利用的是TCP滑动窗口的特性（与服务器未断开）
长时间之后点继续，再次发请求，带range头，继续下载剩余部分（与服务器断开）

扩展

使用Range进行多线程下载

Http 请求头 Range:https://www.cnblogs.com/1995hxt/p/5692050.html

curl -H “Range: bytes=0-1551” http://127.0.0.1:8180/bg-upper.png -v -o 0-1151.png
curl -H “Range: bytes=1552-3103” http://127.0.0.1:8180/bg-upper.png -v -o 1552-end.png
合并 cat 0-1151.png 1552-end.png > filename.png

推送技术总结

发表于 2022-08-05

概述

从客户端是手机APP的角度来理解推送（PUSH），展示的形式有两种：
1. App 推送：消息内容通过手机通知栏（状态栏）展示
2. 应用内消息：各种业务数据推送（通过定义模版或命令号等方式推送给APP内的业务使用）
从Web端角度看理解推送，一般只有网页内消息（跟手机APP的应用内消息是一样的类型）
APP推送：
1. 在线推送（应用级方案）：APP进程控制推送消息，理论上只要APP要获得“手机通知栏”的权限（一般通过在APP内维持长连接来进行推送，但前提是APP已经启动和运行，并且能常驻）
2. 离线推送（系统级方案）：通过手机操作系统或手机厂商提供的通道进行推送。这种推送方式可以在APP未启动的情况下，推送APP的消息。
3. APP进程运行时，应该优先走在线推送，自己的推送系统更快、更有保障。
应用场景
- APP推送：电商内APP（推送促销消息）
- 应用内消息：直播类APP（推送送礼特效消息）
- APP推送和应用内消息都需要：IM类APP（推送用户聊天信息）
从推送的实现角度看，基本可以概括为两种：主动轮询（pull 拉）和长连接（push 推）

实现方式

以下实现方式没有进行严格分类，从原理上看存在相互联系

HTTP轮询
1. 短轮询（Polling）
2. 长轮询（Long-polling）(Nacos和apollo配置中心也是用这种)
- 从TCP的角度看HTTP长轮询：HTTP开启keepalive，服务端保持连接并不需要发额外数据包，有数据时可以立刻推送，跟TCP长连推送无异。展示服务端有点费连接的相关资源，数据包是HTTP相比较大而已。
SSE (Server Sent Event 服务器发送事件)
- sse 单通道，只能服务端向客户端发消息； webscoket 是双通道
- 实现成本较低
- http 协议，服务端响应的是text/event-stream类型的数据流信息
- 场景：站内信、未读消息数、状态更新、股票行情、监控数量等场景
WebSocket
MQTT （通常结合TCP长连接一起使用）
TCP长连接（自定义消息或protobuf等格式）
系统级方案
- Android和IOS本身的消息推送（Android的C2DM和IOS的APNS，系统与服务器建立连接，APP向系统注册关注的消息，实现系统级消息推送）
- 国内Android无法访问Google服务器，所以国内的手机厂商比如小米、OPPO、华为等，都实现来各自的系统级推送。
- 避免维持长连接而导致的过多资源消耗，IM类要求即时的更应该接系统级推送
第三方推送平台
- 集成各种手机平台，各种推送类型，甚至短信等推送
- 简单来说：由专业的平台做专业的事（太麻烦了，我只是想推送了消息，帮我搞定吧。。。）

Reference

说说CDN

发表于 2022-08-02

CDN域名解析流程

浏览器发起HTTP请求到本地DNS服务器，本地DNS服务器使用CNAME的方式，将资源域名重定向到CDN服务

用户机器（比如浏览器）-> LocalDNS
LocalDNS -> 域名授权DNS服务 (返回域名CNAME)
LocalDNS -> 请求CNAME域名（重新走域名解析流程，DNS根服务器，域服务器等）（返回CNAME对应的ip）
LocalDNS -> CNAME对应的CDN服务器（CDN策略，查找出最佳的CDN节点的IP地址）
LocalDNS返回CDN节点IP地址给浏览器
用户机器（比如浏览器）-> CDN节点（若无缓存）
CDN节点 -> 回源服务器拉取资源 (可选)

添加CNAME记录需要在您的域名厂商处配置；CNAME的配置和域名的解析配置一起的

Q&A

服务接口的数据可以使用CDN来缓存？

CDN不仅可以缓存静态资源（图片，视频等），对于一些数据变更不大的接口，可以适当缓存接口数据。比如配置，利用CDN缓存几分钟是合理的。

不能缓存数据的接口，可以使用CDN吗？

结论：可以使用CDN，但注意GET接口响应头设置为不缓存(比如设置 Cache-Control:no-cache)

通过CDN加速回源效果（使用CDN快速传输的特性）
- 比如一般情况下，用户访问通过普通公网，需要经过20个路由才到达服务器
- 使用CDN加速后，通过5CDN节点就到达服务器了（这里涉及服务器端在CDN的接入点、用户端CDN部署的覆盖范围是否足够大）
使用CDN隐藏服务器真实IP,起到提升安全性等作用

Reference

DNS解惑

发表于 2022-08-01

DNS解析流程

不考虑每部分DNS缓存的情况下，DNS解析流程大致如下：

【递归查询】用户机器（比如浏览器）-> 本地DNS服务器
【迭代查询】本地DNS服务器 -> DNS根服务器(返回域服务器)
【迭代查询】本地DNS服务器 -> 域服务器(返回DNS服务器列表)
【迭代查询】本地DNS服务器(选择一个DNS服务器) -> DNS服务器(返回域名对应的IP)（或返回其他权限服务器的IP地址，取决于域名的解析配置）
本地DNS服务器 -> 权限服务器（可选步骤，取决于上一步的返回）
用户机器（根据IP发送请求访问）

https://devconnected.com/how-to-flush-dns-cache-on-linux/
浏览器等各个部分一般会缓存DNS记录一段时间
本地DNS服务器（LocalDNS）使用迭代查询的方式请求；请求发起方（浏览器）使用递归查询的方式请求
递归查询：本机向本地域名服务器发出一次查询请求，就静待最终的结果。如果本地域名服务器无法解析，自己会以DNS客户机的身份向其它域名服务器查询，直到得到最终的IP地址告诉本机
迭代查询：本地域名服务器向根域名服务器查询，根域名服务器告诉它下一步到哪里去查询，然后它再去查，每次它都是以客户机的身份去各个服务器查询。
通俗地说，递归就是把一件事情交给别人，如果事情没有办完，哪怕已经办了很多，都不要把结果告诉我，我要的是你的最终结果，而不是中间结果；如果你没办完，请你找别人办完。
迭代则是我交给你一件事，你能办多少就告诉我你办了多少，然后剩下的事情就由我来办。

域名的管理

.com等国际顶级域名的管理机构是ICANN；.cn等国内域名的管理机构是CNNIC
用whois可以查询域名的相关信息
域名具有管理密码和转移密码，域名转移密码又称为授权码（Authorization code）或域名EPP代码（EPP Key）
域名其实是具有一定的层次结构的，从上到下依次为：根域名、顶级域名（top level domain，TLD）、二级域名、（三级域名）
先来讲讲顶级域名（TLD），即最高层级的域名。简单说，就是网址的最后一个部分。比如，网址www.baidu.com 的顶级域名就是 .com。ICANN 的一项主要工作，就是规定哪些字符串可以当作顶级域名。
ICANN 自己不会去管理这些顶级域名，因为根本管不过来。想想看，顶级域名有1000多个，每个顶级域名下面都有许多批发商，如果每个都要管，就太麻烦了。ICANN 的政策是，每个顶级域名都找一个托管商，该域名的所有事项都由托管商负责。ICANN 只与托管商联系，这样管理起来就容易多了。举例来说，.cn 国家顶级域名的托管商就是中国互联网络信息中心（CNNIC），它决定了 .cn 域名的各种政策。
由于 ICANN 管理着所有的顶级域名，所以它是最高一级的域名节点，被称为根域名（root domain）。在有些场合，www.xxx.com 被写成 www.xxx.com.，即最后还会多出一个点。这个点就是根域名。
理论上，所有域名的查询都必须先查询根域名，因为只有根域名才能告诉你，某个顶级域名由哪台服务器管理。事实上也确实如此，ICANN 维护着一张列表（根域名列表），里面记载着顶级域名和对应的托管商。

DNS服务器类别

权威 DNS

权威 DNS 指域名在域名注册商处所设置的 DNS 服务器地址。该地址决定了该域名的解析管理权（新增，删除，修改等）。比如 DNSPod 的权威服务器：*.dnspod.net, * dnsv3.com 等。当域名设置权威服务器并设置了解析记录后，客户端请求域名时，权威服务器将返回该域名的对应的解析记录信息。

Local DNS

Local DNS 是 DNS 查询中的第一个节点。Local DNS 作为客户端与 DNS 域名服务器的中间人。客户端发送 DNS 查询时，Local DNS 将使用缓存的数据进行响应，或者将向根域名服务器发送请求，接着向根域名服务器发送另一个请求，然后向权威 DNS 发送最后一个请求。收到来自包含已请求 IP 地址的权威 DNS 服务器的响应后，Local DNS 将向客户端发送响应。
在此过程中，Local DNS 将缓存从权威 DNS 服务器收到的信息。当一个客户端请求的域名 IP 地址是另一个客户端最近请求的 IP 地址时，Local DNS 可绕过与域名服务器进行通信的过程，并仅从第二个客户端的缓存中为第一个客户端提供所请求的记录。

公共 DNS

公共DNS，指面向所有互联网用户的全球公共递归域名解析服务。和仅使用本地 LocalDNS 的传统解析服务相比，公共解析服务，一般具备更加“快速”、“稳定”、“安全”互联网访问。

DNS常用命令

dig、 host、nslookup、traceroute、whois

解惑

域名提供商和电信服务提供商之间DNS的关系？

域名提供商(域名注册商)（ICANN等授权的管理机构）；电信服务提供商（ISP）
ISP的DNS：LocalDNS
域名提供商的DNS （腾讯、阿里云等），将自己的dns服务的ip直接在各个ISP中进行登记，使得ISP的DNS服务能转发过来查找，得到域名对应的ip
域名并不依赖平台，比如阿里万网只是个注册商，注册完域名后有相应的转移密码。转移密码有多种用途，比如可以在多个DNS服务商托管域名解析（有的域名注册商不一定有对应的DNS服务，而且在多个DNS服务商解析可以起到容灾作用）

运营商DNS和公共DNS

如何不特意去设置，我们用的就是运营商DNS（由DHCP分配）
目前国内电信运营商通过使用DNS劫持和DNS污染的方法，干扰用户正常上网，使得用户无法访问众多国外常用服务，因此可以使用公共DNS

自己创建的域名怎么让其他dns服务器解析

除非用户自行设置指定你的dns服务公网ip，否则只有成为认证通过的注册服务商才行
比如阿里云域名的解析生效，第一步是阿里云 DNS 必须首先生效，然后等待世界各地 Local DNS 生效，可以通俗的理解为各大电信运营管理的 DNS 需要及时同步阿里云 DNS 解析记录，才能最终生效。网站是否能访问，直接相关的是 Local DNS，阿里云解析都是实时生效的，一般只需几秒即可同步到各地 Local DNS 上，但各地 Local DNS 均有缓存机制，解析的最终生效取决于各运营商刷新时间。

DNS解析相关疑问

DNS协议是应用层的协议，解析过程发生在用户态。
DNS协议既使用了UDP，也使用了TCP，使用的端口号都为 53。大多数情况下 DNS 都使用 UDP 进行传输。
DNS在区域传输的时候使用TCP协议，其他时候使用UDP协议；DNS区域传输的时候使用TCP协议
举个例子：浏览器返回某个HTTP服务
1. 浏览器调用“DNS解析模块”发出UDP请求得到域名的ip（DNS 应用层）
2. 浏览器调用TCP（内核系统调用）发出HTTP请求（TCP 传输层）
3. TCP通过ARP协议得到mac地址（ARP 数据链路层）
“DNS解析模块” 是在哪里实现的？
1. 程序自行解析实现（从/etc/resolv.conf中取出本地dns server地址列表，发送DNS请求(UDP报文)并获得结果）
2. 调用到c标准库的getaddrinfo或getnameinfo函数
  - 要想知道getaddrinfo是如何查询信息的，可以用strace工具，追踪getaddrinfo函数在执行时打开了哪些文件
  - resolv.conf是各种操作系统域名系统解析器（DNS Resolver）的配置文件。每当一个程序需要通过域名来访问Internet上面的其它主机时，需要利用Resolver库函数将域名转换成对应的IP，然后才可进行访问。
  - 域名系统解析器（DNS Resolver）并非一个可执行程序，而是C语言的一系列库函数，用于解析resolv.conf获取域名对应的IP。
3. 操作系统中并不存在“DNS 查询”这个系统调用; 不同程序可能采用不同的策略获取名字对应的 IP 地址

dns-resolver相关

https://docs.microsoft.com/en-us/windows/win32/dns/dns-resolvers
https://datacadamia.com/os/linux/resolv.conf
DNS Resolver Module
- The DNS resolver module provides a way for kernel services to make DNS queries by way of requesting a key of key type dns_resolver. These queries are upcalled to userspace through /sbin/request-key.

Reference

谈谈跨域

发表于 2022-07-20

JQuery的jsonp的success与jsonpCallback的关系:https://www.cnblogs.com/non-clockwork-cheng/p/6637491.html,
https://www.cnblogs.com/tapt/p/6524946.html

$.ajax({
              type: "get",
              async:false,
              url: "http://192.168.1.102:8080/carop/jsonp",
              dataType: "jsonp",
              jsonpCallback:"jsonpCallback",              
              success: function(data){
              alert(data.name+"\n "+data.tel);
              }
 });

jsonp和jsonpcallback的使用:https://www.cnblogs.com/zhangruiqi/p/7880642.html

1. jsonp、jsonpCallback  jsonp跨域时可以自定义的两个参数
2. jsonp: 回掉函数名的参数名，默认callback，服务端通过它来获取到回调函数名
3. jsonpCallback: 回调函数名，默认jquery自动生成
4. 指定jsonpCallback时可以将回掉函数写在ajax外面做其他操作，不指定时不能这样做，只能在success里做操作

一般jquery跨域用到的两个方法为：$.ajax 和$.getJSON

最后，仔细安静下来，细读 json 官方文档后发现这么一段：

JSON数据是一种能很方便通过JavaScript解析的结构化数据。如果获取的数据文件存放在远程服务器上（域名不同，也就是跨域获取数据），则需要使用jsonp类型。使用这种类型的话，会创建一个查询字符串参数 callback=? ，这个参数会加在请求的URL后面。服务器端应当在JSON数据前加上回调函数名，以便完成一个有效的JSONP请求。如果要指定回调函数的参数名来取代默认的callback，可以通过设置$.ajax()的jsonp参数。

其实jquery跨域的原理是通过外链

Java跨平台能完全做到一次编写到处运行？

发表于 2022-07-05

最近定位一个问题，花了不少时间。事后回想起来挺低级的，在此记录一下。

问题

spring i18n, 在windows和mac生效，在linux不生效。

原因

资源文件的名字为小写（message_zh_hant.proprties）
而文件读取时包含大写（message_zh_Hant.proprties）（这里不得不吐槽一下，spring无论请求参数传的是大写还是小写，最终都会转成大写去读文件，而且这么简单的功能，代码写得及其复杂，浪费了不少时间去debug）
windows和mac大小写不敏感，所以能读取文件成功，而linux则大小写敏感，则读取不成功（说好的Java跨平台呢？但跨平台包括处理这种不兼容的问题？似乎很难界定。）

总结

windows和mac文件名对大小写不敏感，而linux则大小写敏感；
即使使用Java编写代码，特殊的场景还是需要考虑各平台的兼容问题。

开发golang程序和进行内网穿透，作为微信公众号服务器

发表于 2022-06-01

一直想部署一个私有服务，平常在外的时候可以为自己提供服务。
私有服务的好处是，可以根据自己的需求，开发程序，提供个人定制化的服务

服务器的选择

阿里云、腾讯云等
- 优点：使用方便，只要有网络就可以连上
- 缺点：有持续产生的费用，对于个人服务来说，平常几乎都是闲置，性价比很低
自建服务器
- 优点：总体成本低，购买服务器后，后续只有有电有网就行，无需其他额外成本
- 缺点：需要外网能访问（需要绑定外网ip或者代理接入转发）

本着能省就省的原则，最终还是采用了方案2 ：上淘宝买一个一百多块的小型服务器！

如何使外网环境能访问到服务器

服务器有了之后，通过网线连接到家庭网络即可正常上网了，那么外网环境怎么访问呢？
通过一番研究之后，最终决定通过在服务器上部署ngrok代理来实现，不知道啥是ngrok的自行搜索即可

编程语言选择

本人平常工作都是使用Java，但经过一番考虑之后，我最终选择了Go作为开发语言

想学习，通过实践熟悉
足够轻量，打包成一个二进制文件即可，特别适合这种低配版服务器

个人Go程序代码：https://github.com/Kingson4Wu/mp_weixin_server

前端终端选择

平常在外都是使用android的手机，但是作为后端开发，本人只会android的hello world。
有考虑使用网页，但是现在前端很卷了，用传统的html+js开发，以我的水平开发出来，至少前期体验也一般。
经过一番考虑，就在决定直接通过个人的微信公众号来作为前端，在公众号后台配置自己的服务器地址即可

微信通知的实现

平常自己有一些个性定时任务，需要通知消息到自己，使用微信来通知是最好的，毕竟大家目前都是微信的重度用户了。
但现在微信对公众号的通知限制越来越多了，最后我选择通过发送邮件的方式来实现。在微信配置QQ邮箱接收邮件通知即可。

服务架构

外网环境下如何进行服务部署更新

平常在家庭网络下，开发Go程序，本地编译打包成二进制文件，上传到服务器更新程序即可
在外网环境下，使用花生壳等端口映射软件即可。我使用花生壳映射端口后，就可以通过ssh登录到家里的服务器，接下来就可以为所欲为了。

部署流程

结论总结

家庭网络 + 小型服务器 + Go程序 + ngrok + 微信公众号 + 邮箱通知 + 花生壳

Reference

golang如何优雅的实现重启服务(fvbock/endless)

算法基础总结

发表于 2022-05-10

O这个符号的意思是“忽略重要项以外的内容”，读音同Order。O（n2）的含义就是“算法的运行时间最长也就是n2的常数倍”，准确的定义请参考相关专业书籍。重点在于，通过这种表示方法，我们可以直观地了解算法的时间复杂度
当我们知道选择排序的时间复杂度为O（n2）、快速排序的时间复杂度为O（nlogn）时，很快就能判断出快速排序的运算更为高速。二者的运行时间根据输入n产生的变化程度也一目了然。

一、链表

二、数组

三、栈

四、队列

五、哈希表

六、堆

堆是一种图的树形结构，被用于实现“优先队列”（priority queues）
优先队列是一种数据结构，可以自由添加数据，但取出数据时要从最小值开始按顺序取出
如果需要频繁地从管理的数据中取出最小值，那么使用堆来操作会非常方便。

七、二叉查找树

二叉查找树（又叫作二叉搜索树或二叉排序树）是一种数据结构，采用了图的树形结构
二叉查找树有两个性质。第一个是每个结点的值均大于其左子树上任意一个结点的值。
有很多以二叉查找树为基础扩展的数据结构，比如“平衡二叉查找树”。这种数据结构可以修正形状不均衡的树，让其始终保持均衡形态，以提高查找效率。
种子结点数可以自由设定，并且形状均衡的树便是B树。

图

由顶点和连接每对顶点的边所构成的图形就是图。
这个值叫作边的“权重”或者“权”，加了权的图被称为“加权图”。没有权的边只能表示两个顶点的连接状态，而有权的边就可以表示顶点之间的“连接程度”
有向图、无向图

广度优先搜索

广度优先搜索会优先从离起点近的顶点开始搜索。
候补顶点是用“先入先出”（FIFO）的方式来管理的，因此可以使用“队列”这个数据结构。
广度优先搜索的特征为从起点开始，由近及远进行广泛的搜索。因此，目标顶点离起点越近，搜索结束得就越快。

深度优先搜索

深度优先搜索会沿着一条路径不断往下搜索直到不能再继续为止，然后再折返，开始搜索下一条候补路径。
此处，候补顶点是用“后入先出”（LIFO）的方式来管理的，因此可以使用“栈”这个数据结构。
广度优先搜索选择的是最早成为候补的顶点，因为顶点离起点越近就越早成为候补，所以会从离起点近的地方开始按顺序搜索；而深度优先搜索选择的则是最新成为候补的顶点，所以会一路往下，沿着新发现的路径不断深入搜索。

贝尔曼-福特算法

贝尔曼-福特（Bellman-Ford）算法是一种在图中求解最短路径问题的算法。最短路径问题就是在加权图指定了起点和终点的前提下，寻找从起点到终点的路径中权重总和最小的那条路径。
贝尔曼也因为提出了该算法中的一个重要分类“动态规划”而被世人所熟知。

狄克斯特拉算法

狄克斯特拉（Dijkstra）算法也是求解最短路径问题的算法，使用它可以求得从起点到终点的路径中权重总和最小的那条路径路径。

A*算法

A（A-Star）算法也是一种在图中求解最短路径问题的算法，由狄克斯特拉算法发展而来。狄克斯特拉算法会从离起点近的顶点开始，按顺序求出起点到各个顶点的最短路径。也就是说，一些离终点较远的顶点的最短路径也会被计算出来，但这部分其实是无用的。与之不同，A就会预先估算一个值，并利用这个值来省去一些无用的计算。

Reference

[我的第一本算法书] - 宫崎修一石田保辉

高效工作方法论总结

发表于 2022-05-07

思考维度

事前, 事中, 事后
从三个维度预防，及时发现，止损三个出发
what when why who how
5W3H(what、when、why、who、where、how、how much、how feel)
金字塔思维: 主治：思维混乱，分不清主次重点 - 提高逻辑性和条理性; 总-分-总过去-现在-将来第一-第二-第三.
STAR 法则: 主治：不知道如何表达 - 讲述故事的绝佳手段; 情境(situation)、任务(task)、行动(action)、结果(result)
SMART 原则: 主治：不知道如何着手做目标管理 - 制定目标的黄金准则; 目标具体(Specific)、可度量(Measurable)、可实现(Attainable)、现实性(Realistic)、时限(Time bound)
PDCA 循环：主治：工作计划性差, 自律性弱 - 过程管理: 持续反馈->持续改进；计划（plan）、执行（do）、检查（check）、调整（Adjust）
四象限法则: 主治：时间分配不合理- 尽量在做最重要的事情;

结构化思维

表达要有逻辑(所有的逻辑关系都在这四种顺序之内)

演绎（因果）顺序
时间（步骤）顺序
空间（结构）顺序
程度（重要性）顺序

做事要有套路

5W2H:Why、Who、When、Where、What、How 和 How much

建立中心

定义清楚要解决的问题，要明确目标
- 自上而下:适用于问题比较明确的情况，我们只需要找到问题的核心要素即可，然后进行展开即可。
- 自下而上:对于问题不够明确的情况，我们需要对多种杂乱的内容，进行分类、剪枝、归纳汇总成一个中心。
抽象层次越高，要解决的问题域越宽，外延越大

结构化分解

分解的策略就是我们上文提到的四种逻辑顺序，即演绎顺序、时间顺序、空间顺序和程度顺序
在做空间分解的时候，要注意满足 MECE（Mutually Exclusive Collectively Exhaustive，相互独立，完全穷尽）原则

合理安排自己的时间

每天提前一小时醒来
每天提前 15 分钟到公司
下班前花 15 分钟总结
减少玩手机的时候
把时间切割成小块
碎片化时间利用
给休息生活留出时间

抽象思维：帮助我们快速抽取面对问题的关键要素和本质，可以是其他能力的“元能力”
分层思维：帮助我们拆解问题，分而治之，划清问题和职责边界
归纳思维：帮助我们从个性问题中抽象出问题的一般规律和得出共同结论
结构化思维：帮助我们沉淀自己的知识树，逐步系统性的思考问题

深度工作总结

如果你无法学习，就无法成功
无干扰状态下保持专注
高质量工作产出=时间×专注度
转移工作、注意力残留 -> 专注、深度工作
深度工作并非是我们的经济中唯一有价值的技能，不培养这种能力也有可能做得很好，但是不需要深度工作的职业会越来越少。
最小阻力原则
忙碌代表生产能力（Busyness as Proxy for Productivity）：在工作中，对于生产能力和价值没有明确的指标时，很多知识工作者都会采用工业时代关于生产能力的指标，以可视的方式完成很多事情。
支持深度工作往往要抵制新的高科技
当工作中没有明确目标时，围绕浮浅工作的表面忙碌会成为一种本能
工作其实比休闲时光更容易带来享受？
意志力是有限的
培养深度工作的习惯，关键在于越过良好的意图，在工作生活中加入一些特别设计的惯例和固定程序，使得进入并保持高度专注状态消耗的意志力最小化。！！！！！
选定你的深度哲学（节奏哲学）、并习惯化
恰当展开协作可以提升你在职业生活中深度工作的质量
这种隔音办公室与宽阔公共空间的组合，形成了中心辐射型的创新建筑结构，在这里偶遇的意外发现和与世隔绝的深度思考都能实现。
专注于少量“极端重要的目标”
引领性指标
专注于极度重要目标上的深度工作状态时间
4DX框架下的4种原则！！！
在整个4DX的实验过程中，目标的明晰性，辅以引领性指标计分板提供的简单但却难以回避的反馈，促使我达到了此前从未实现的深度状态。
定期放松大脑！！工作日结束的时候，在第二天早晨到来之前，屏蔽掉对工作问题的担忧。
定期休息大脑可以提升深度工作的质量。工作时，努力工作。完成时，就放松下来。
不要不断分心，而要不断专注
设定一个几乎不可能的时间期限；深度工作需要专注的强度远远超出了大部分知识工作者的舒适区。
有成果的冥想
远离社交媒体
在晚上或周末到来之前就确定要做的事情是十分重要的。（避免陷入其他无效的诱惑）
人的智力系统可以进行长时间的高强度活动：它不像人的手脚一样会疲倦。除睡觉以外，它只需要变化，而不是停止。！！！
如果你想抵御娱乐网站对你时间和精力的诱惑，那么就给大脑找一些高质量的替代活动。这样不仅可以使我们避免分心，保持专注的能力，同时还有可能实现本内特的宏伟目标：体验到何为生活，而不仅仅是生存。
减少浮浅工作在我们日程中的分量，而不是将其消除
一天的每一分钟都要做好计划（笔记本）
深度工作要求你尊重自己的时间。要做到真正尊重时间，下面这一条建议是个很不错的开端：提前决定你一天的每一分钟要做什么工作。
5点半之前结束工作。固定日程生产力。
变得不容易联系到；文档化

粗浅概括

其他基础

HTTP

“队头堵塞” （线头阻塞）（Head-of-line blocking）（HOLB）

管道机制(Pipelining)

HTTPS

jks、pfx和cer 证书文件

权威证书颁发的公钥匙一般是预装的

HTTP/2

多路复用(Multiplexing)

加密

重用连接（针对浏览器）

头部压缩

推送

HTTP/3

TCP的限制

新特性

采用HTTP/3的限制

Q&A

HTTP 与 TCP backlog关系

关于 HTTP keepalive

HTTP keepalive VS TCP keepalive

Chrome中HTTP下载续传原理

HTTP连接复用时，同一个连接上的多个请求和响应如何对应上？

可以外网使用HTTP/3，再转发到内网的HTTP服务？

使用HTTPS还存在中间人攻击？

扩展

cURL 发 HTTP/2请求

HTTP/3 握手优化

Reference

Range

chrome 版本58

总结

扩展

使用Range进行多线程下载

概述

实现方式

Reference

相关名词

CDN域名解析流程

Q&A

服务接口的数据可以使用CDN来缓存？

不能缓存数据的接口，可以使用CDN吗？

Reference

相关名词

DNS解析流程

域名的管理

DNS服务器类别

权威 DNS

Local DNS

公共 DNS

DNS常用命令

解惑

域名提供商和电信服务提供商之间DNS的关系？

运营商DNS和公共DNS

自己创建的域名怎么让其他dns服务器解析

DNS解析相关疑问

dns-resolver相关

Reference

问题

原因

总结

服务器的选择

如何使外网环境能访问到服务器

编程语言选择

前端终端选择

微信通知的实现

服务架构

外网环境下如何进行服务部署更新

部署流程

结论总结

Reference

一、链表

二、数组

三、栈

四、队列

五、哈希表

六、堆

七、二叉查找树

图