RUN__IT # HTTP协议--三次握手四次挥手

本文深入探讨了HTTP协议的基础知识,包括它作为基于TCP的协议的角色,与UDP的区别,以及TCP的三次握手和四次挥手过程。同时,介绍了HTTP请求和响应的结构,特别是状态码如200 OK、404 Not Found和500 Internal Server Error的含义。HTTP消息由Header和可选Body组成,Body的内容类型由Content-Type定义,可能需要根据Content-Encoding进行解压缩。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

HTTP,HyperText Transfer Protocol。超文本传输协议,是互联网上应用最为广泛的一种网络协议。基于TCP的协议,HTTP是一个客户端和服务器端请求和应答的标准。
udp是User Datagram Protocol的简称,是用户数据报协议。无连接的传输层协议。
tcp是Transmission Control Protocol,缩写为 TCP。是传输控制协议。是一种面向连接的。可靠的。基于字节流的传输层通信协议。

TCP的三次握手
在这里插入图片描述

1、第一次握手:(客户端:服务器在吗?)

建立连接时,客户端A发生SYN包(SYN=j)到服务器B

并进入SYN_SEND状态,等待服务器B确认

2、第二次握手:(服务器:收到了,在的,)

服务器B收到SYN包,必须确认客户A的SYN,ACK=j+1

同时自己也发送一个SYN包,SYN=k

即,SYN+ACK包,此时服务器进入SYN_RECV状态

3、第三次握手:(客户端:我要发数据了)

客户端A收到服务器B的SYN+ACK包

向服务器B发送确认包ACK(ACK=k+1)

此包发送完毕,客户端A和服务器B进入ESTABLISHED状态,完成三次握手

TCP的四次挥手
在这里插入图片描述


1、客户端A发送一个FIN.用来关闭客户A到服务器B的数据传送(报文段4)(客户端:我要关了)

2、服务器B收到这个FIN. 它发回一个ACK,确认序号为收到的序号+1(报文段5)。和SYN一样,一个FIN将占用一个序号(服务端:好的,收到)

3、服务器B关闭与客户端A的连接,发送一个FIN给客户端A(报文段6)(服务端:我也要关了)

4、客户端A发回ACK报文确认,并将确认序号设置为序号加1(报文段7)(客户端:好的,收到)
服务器如何复用同一个端口而不会提示端口被占用

tcp_server_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

允许地址重用

str.splitlines()按照行('\r', '\n', '\r\n')分隔,返回一个包含各行作为元素的列表

浏览器Brower ---->服务器server发送的请求格式如下: 请求头 request header

https://www.baidu.com/a/b/login.html

127.0.0.1:7890

GET /a/b/login.html HTTP/1.1  # 请求行   GET是请求方式  /index.html是资源路径  HTTP/1.1是协议版本
Host: 127.0.0.1:8080
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.75 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8

服务器—>浏览器回送的数据格式如下: 响应头 response header

HTTP/1.1 200 OK  # 响应行   HTTP/1.1是协议版本  200表示的是状态码
Bdpagetype: 1
Bdqid: 0xe87cb3f700023783
Bduserid: 0
Cache-Control: private
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Cxy_all: baidu+55617f8533383cbe48d5d2b7dc84b7f0
Date: Fri, 20 Oct 2017 00:59:55 GMT
Expires: Fri, 20 Oct 2017 00:59:11 GMT
Server: BWS/1.1
Set-Cookie: BDSVRTM=0; path=/
Set-Cookie: BD_HOME=0; path=/
Set-Cookie: H_PS_PSSID=1463_21080_17001_20929; path=/; domain=.baidu.com
Strict-Transport-Security: max-age=172800
Vary: Accept-Encoding
X-Powered-By: HPHP
X-Ua-Compatible: IE=Edge,chrome=1
Transfer-Encoding: chunked

<h1>haha</h1>  # 响应体 response body

200表示⼀个成功的响应,后⾯的OK是说明。

如果返回的不是200,那么往往有其他的功能,例如,失败的响应有404 Not Found:⽹⻚不存在

500 Internal Server Error:服务器内部出错

…等等…

每个HTTP请求和响应都遵循相同的格式,⼀个HTTP包含Header和Body两部分,其中Body是可选的。
HTTP响应如果包含body,也是通过\r\n\r\n来分隔的。
请再次注意,Body的数据类型由Content-Type头来确定,如果是⽹⻚,Body就是⽂本,如果是图⽚,Body就是图⽚的⼆进制数据。
当存在Content-Encoding时,Body数据是被压缩的,最常⻅的压缩⽅式是gzip,所以,看到Content-Encoding: gzip时,需要将Body数据先解压缩,才能得到真正的数据。压缩的⽬的在于减少Body的⼤⼩,加快⽹络传输。

<think>好的,我现在要帮用户理解Nginx中的upstream配置,特别是针对PHP-FPM的部分。首先,用户给出的配置是: upstream php-fpm { server unix:/run/php-fpm/www.sock; } 我需要先回忆一下Nginx的upstream模块的作用。upstream主要用于定义后端服务器组,实现负载均衡和代理。这里用户使用的是Unix套接字,而不是IP地址,说明PHP-FPM是通过本地socket通信的,这通常比TCP更快,因为没有网络开销。 接下来,我需要分析这个配置的具体作用。用户可能是在配置Nginx与PHP-FPM的通信,所以需要解释upstream块在这里的意义。首先,upstream定义了一个名为php-fpm的后端服务器组,里面只有一个server条目,指向Unix套接字文件。这个名称php-fpm在之后的fastcgi_pass指令中会被引用,比如fastcgi_pass php-fpm;。 然后,要解释为什么使用Unix套接字而不是IP。可能的原因包括性能更好,安全性更高,因为不需要开放网络端口。同时,需要确认套接字文件的路径是否正确,通常路径是/run/php-fpm/www.sock,但不同的系统或安装方式可能会有差异,比如有些可能在/var/run/目录下。 接下来,用户可能需要了解如何扩展这个配置,比如添加多个后端服务器实现负载均衡。比如可以添加多个server行,每个指向不同的socket或IP,并设置权重或其他参数。但当前配置只有一个,所以可能用户的环境是单机部署,不需要负载均衡。 还要提到高可用性的考虑,虽然当前只有一个server,但如果有多个,Nginx会自动处理故障转移。不过用户可能现在只是基础配置,暂时不需要复杂设置。 然后,需要指出常见的配置错误,比如套接字文件路径不正确,或者权限问题。Nginx的工作进程(通常是www-data或nginx用户)必须有权限访问该套接字文件。可能需要检查文件权限和所属用户组,确保Nginx可以读写。 另外,配置中的upstream名称php-fpm是自定义的,用户可以根据需要改名,但要保证在fastcgi_pass中引用一致。比如如果upstream叫backend,那么fastcgi_pass backend;。 可能还需要提到健康检查的相关配置,虽然默认情况下Nginx没有主动的健康检查,但可以手动设置max_fails和fail_timeout等参数来检测后端状态。不过在这个例子中,用户可能还没涉及到这些高级设置,所以暂时不需要深入,但可以作为扩展知识提及。 最后,总结这个配置的作用:定义了一个名为php-fpm的后端服务,使用本地Unix套接字与PHP-FPM进程通信,提升性能,并确保Nginx正确代理请求到PHP处理器。同时,提醒用户注意路径和权限问题,以及可能的扩展选项。</think>--- ### **一、核心作用解析** ```nginx upstream php-fpm { server unix:/run/php-fpm/www.sock; } ``` 这是Nginx用于定义反向代理后端服务的标准配置模块,在PHP-FPM场景中实现**进程间通信路由**。具体作用分解: | 配置元素 | 功能说明 | |------------------------|--------------------------------------------------------------------------| | `upstream php-fpm` | 定义名为"php-fpm"的后端服务组(逻辑分组) | | `server unix:...` | 指定使用Unix域套接字(非TCP)进行通信 | | `/run/php-fpm/www.sock`| PHP-FPM监听的套接字文件路径(需与PHP-FPM配置中的`listen`参数绝对一致) | --- ### **二、通信架构示意图** ```bash Nginx Worker进程 ⇩ [unix:/run/php-fpm/www.sock] # 内核级IPC通道 ⇩ PHP-FPM Master进程 ⇩ PHP-FPM Worker进程池 ``` **性能优势**:相比`127.0.0.1:9000`的TCP连接方式: - 减少TCP三次握手/四次挥手开销 - 避免端口号冲突风险 - 内核直接处理数据拷贝,吞吐量提升约30% --- ### **三、配置深度验证** #### 1. **套接字文件存在性检查** ```bash ls -l /run/php-fpm/www.sock # 预期输出: # srw-rw---- 1 www-data www-data 0 Jul 15 10:00 /run/php-fpm/www.sock ``` **关键指标**: - 文件类型为`s`(socket) - 所属用户/组需与Nginx worker进程一致(通常为`www-data`或`nginx`) #### 2. **PHP-FPM配置对应验证** 检查`php-fpm.conf`或`www.conf`: ```ini ; 确保监听路径完全一致 listen = /run/php-fpm/www.sock ; 权限设置需允许Nginx进程访问 listen.owner = www-data listen.group = www-data listen.mode = 0660 ``` #### 3. **Nginx连接测试** ```bash sudo -u www-data curl --unix-socket /run/php-fpm/www.sock http://localhost/status ``` 预期返回PHP-FPM状态信息(需开启`pm.status_path`配置) --- ### **四、负载均衡扩展配置** #### 基础负载均衡 ```nginx upstream php-fpm-cluster { server unix:/run/php-fpm/node1.sock weight=3; # 权重占比3/7 server unix:/run/php-fpm/node2.sock weight=4; # 权重占比4/7 least_conn; # 可选负载均衡算法 } ``` #### 健康检查机制 ```nginx server unix:/run/php-fpm/bak.sock backup; # 定义备用服务器 check interval=3000 rise=2 fall=3 timeout=1000 type=http; check_http_send "GET /health-check HTTP/1.0\r\n\r\n"; check_http_expect_alive http_2xx http_3xx; ``` --- ### **五、故障排查指南** #### 1. **连接拒绝错误** ```log connect() to unix:/run/php-fpm/www.sock failed (2: No such file or directory) ``` **解决方案**: - 确认PHP-FPM服务已启动:`systemctl status php-fpm` - 检查套接字文件生成路径是否正确 #### 2. **权限被拒绝错误** ```log connect() to unix:/run/php-fpm/www.sock failed (13: Permission denied) ``` **权限修复流程**: ```bash chown www-data:www-data /run/php-fpm/www.sock chmod 660 /run/php-fpm/www.sock setsebool -P httpd_unified 1 # SELinux环境专用 ``` #### 3. **资源耗尽问题** ```log upstream timed out (110: Connection timed out) ``` **优化方向**: - 调整PHP-FPM池配置: ```ini pm.max_children = 50 pm.start_servers = 5 pm.min_spare_servers = 2 pm.max_spare_servers = 8 ``` - 增加Nginx的`fastcgi_read_timeout`值 --- ### **六、生产环境最佳实践** #### 1. 专用socket目录 ```nginx upstream php-fpm { server unix:/dev/shm/php-fpm.sock; # 使用内存文件系统 } ``` 优势:完全避免磁盘I/O,提升约15%的QPS #### 2. 多进程组隔离 ```nginx upstream api-fpm { server unix:/run/php-fpm/api.sock; } upstream web-fpm { server unix:/run/php-fpm/web.sock; } ``` 对应PHP-FPM配置: ```ini [api] listen = /run/php-fpm/api.sock [web] listen = /run/php-fpm/web.sock ``` #### 3. 内核参数优化 ```bash # 提高套接字缓冲区 sysctl -w net.core.rmem_max=16777216 sysctl -w net.core.wmem_max=16777216 ``` --- **最终推荐配置示例**: ```nginx upstream php-fpm { server unix:/dev/shm/php-fpm.sock weight=5; server unix:/run/php-fpm/backup.sock backup; keepalive 50; # 维持长连接 keepalive_requests 10000; # 单个连接最大请求数 keepalive_timeout 60s; } server { location ~ \.php$ { fastcgi_pass php-fpm; fastcgi_keep_conn on; # 启用keepalive } } ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值