web服务如何发出请求

浏览器敲下回车那一刻，服发出Web服务请求就已经在路上了。请求它不是服发出什么抽象概念，而是请求一串实实在在的字节，从你的服发出网卡出发，穿过路由器、请求光猫、服发出运营商骨干网，请求最后抵达某台服务器的服发出网卡。整个过程通常不到200毫秒，请求但里面发生的服发出事足够写一本书。

先看最表层。请求当你在地址栏输入 https://api.example.com/users，服发出浏览器做的请求第一件事是解析URL。协议是服发出https，主机是api.example.com，路径是/users。接着它要找到这台主机对应的IP地址——DNS查询。如果本地缓存没有，就得向递归DNS服务器要，递归服务器再一层层问根域名服务器、顶级域名服务器、权威域名服务器。这个环节有时候快得无感，有时候能卡你三秒，尤其是第一次访问某个域名的时候。

拿到IP之后，TCP三次握手开始。SYN、SYN-ACK、ACK，三个包打个来回，连接才算建立。如果是HTTPS，还要再多几轮TLS握手：客户端说“我支持这些加密套件”，服务端说“那用这个，这是我的证书”，客户端验证证书、生成会话密钥，双方确认。TLS 1.3把这一步压缩到一次往返，TLS 1.2得两次。别小看这一来一回，在跨太平洋光缆上就是几十毫秒的差距。

连接就绪，HTTP请求才真正发出去。一个典型的GET请求长这样：

GET /users HTTP/1.1 Host: api.example.com User-Agent: Mozilla/5.0 ... Accept: application/json Authorization: Bearer eyJhbGciOi... 

请求行、请求头、空行、请求体（GET通常没有体）。服务端收到后，框架层开始解析：Nginx转发给上游应用，应用路由匹配到对应的处理函数，查数据库、拼JSON、写响应。响应也是同样的结构——状态行、响应头、空行、响应体。200 OK，Content-Type: application/json，然后是一坨用户数据。

这里面有个容易忽略的细节：HTTP/1.1默认开启Keep-Alive，一个TCP连接可以复用多次请求。但浏览器对同一域名的并发连接数有限制，Chrome大概是6个。所以前端优化里常说的“域名分片”，就是把资源分散到多个子域名，绕过这个限制。HTTP/2多路复用之后这招就过时了，一个连接上可以并行跑几百个流。

再说说服务端之间的请求。微服务架构里，A服务调B服务，走的也是HTTP，只不过客户端从浏览器换成了编程语言里的HTTP库。Java用HttpClient，Go用net/http，Python用requests。这些库帮你封装了连接池、超时、重试，但底层干的事一模一样——建连接、发字节、等响应。区别在于服务间调用往往更在意延迟和熔断，所以有了gRPC、Thrift这些基于HTTP/2的RPC框架，用Protobuf替代JSON，省带宽也省序列化时间。

我见过不少线上问题出在超时设置上。浏览器默认超时可能30秒，但移动网络下用户等3秒就烦了。服务端调下游如果没设超时，一个慢查询能把整个线程池拖垮。请求发出去容易，控制它什么时候回来、回来之后怎么处理，才是真功夫。

还有个反直觉的事实：DNS解析和TCP握手的时间，经常比服务端处理请求的时间还长。一个API响应50毫秒，但DNS加TLS可能花了150毫秒。所以CDN和边缘节点才那么重要——把连接建立的过程挪到离用户更近的地方。

最后提一句，WebSocket和SSE也是“发出请求”的变体。WebSocket先发一个HTTP Upgrade请求，握手成功后协议切换，之后就是全双工通信。SSE则是服务端保持一个长连接，持续往客户端推文本流。它们没有改变请求的本质，只是把“一问一答”变成了“一直聊”。