http keepalive
http 초기에는 각 http 요청에 tpc 소켓 연결을 열어야 했고, 한 번 사용하고 나면 tcp 연결이 끊어졌습니다. 연결 유지를 사용하면 이러한 상황이 개선될 수 있습니다. 즉, 연결을 끊지 않고 하나의 TCP 연결에서 여러 데이터 복사본을 연속적으로 전송할 수 있습니다. keep-alive 메커니즘을 사용하면 TCP 연결 설정 시간이 줄어들 수 있으며 이는 또한 time_wait 상태 연결이 줄어들 수 있음을 의미하므로 성능이 향상되고 httpd 서버의 처리 속도가 높아집니다(TCP 연결이 적다는 것은 시스템 수가 적다는 것을 의미합니다). 커널 호출, 소켓 accept() 및 close() 호출). 그러나 연결 유지는 공짜가 아닙니다. 장기간 TCP 연결을 사용하면 시스템 리소스가 잘못 사용될 수 있습니다. 부적절하게 구성된 연결 유지는 때때로 연결을 재사용하는 것보다 더 큰 손실을 초래할 수 있습니다. 따라서 연결 유지 시간 제한을 올바르게 설정하는 것이 매우 중요합니다.
keepalvie timeout
httpd 데몬은 일반적으로 연결 유지 시간 초과 시간 설정 매개변수를 제공합니다. 예를 들어 nginx의 keepalive_timeout 및 apache의 keepalivetimeout이 있습니다. 이 keepalive_timout 시간 값은 http에 의해 생성된 TCP 연결이 마지막 응답을 전송한 후 연결 닫기를 시작하기 전에 keepalive_timeout 초를 유지해야 함을 의미합니다. httpd 데몬이 응답 전송을 마치면 즉시 해당 TCP 연결을 닫아야 합니다. keepalive_timeout을 설정한 후 httpd 데몬은 "조금 더 기다려서 브라우저에서 추가 요청이 있는지 확인하세요."라고 말하고 싶어합니다. . 이는 keepalive_timeout 시간입니다. 이 대기 시간 동안 데몬 프로세스가 브라우저로부터 http 요청을 받지 못하면 http 연결이 닫힙니다.
테스트를 용이하게 하기 위해 스크립트를 작성했습니다
<?php sleep(60); //为了便于分析测试,会根据测试进行调整 echo "www.jb51.net"; ?>
1. keepalive_timeout 시간이 0일 때, 즉 keep-alive가 활성화되지 않은 경우 tcp 연결의 수명 주기
#tcpdump -n host 218.1.57.236 and port 80
20:36:50.792731 ip 218.1.57.236.43052 > 222.73.211.215.http: s 1520902589:1520902589(0) win 65535 20:36:50.792798 ip 222.73.211.215.http > 218.1.57.236.43052: s 290378256:290378256(0) ack 1520902590 win 5840 20:36:50.801629 ip 218.1.57.236.43052 > 222.73.211.215.http: . ack 1 win 3276820:36:50.801838 ip 218.1.57.236.43052 > 222.73.211.215.http: p 1:797(796) ack 1 win 32768 20:36:50.801843 ip 222.73.211.215.http > 218.1.57.236.43052: . ack 797 win 5920:37:50.803230 ip 222.73.211.215.http > 218.1.57.236.43052: p 1:287(286) ack 797 win 59 20:37:50.803289 ip 222.73.211.215.http > 218.1.57.236.43052: f 287:287(0) ack 797 win 59 20:37:50.893396 ip 218.1.57.236.43052 > 222.73.211.215.http: . ack 288 win 32625 20:37:50.894249 ip 218.1.57.236.43052 > 222.73.211.215.http: f 797:797(0) ack 288 win 32625 20:37:50.894252 ip 222.73.211.215.http > 218.1.57.236.43052: . ack 798 win 59
1~3번째 줄은 tcp 3을 설정합니다. -way 핸드셰이크, 연결 설정. 설정된 연결을 통해 첫 번째 http 요청을 보내는 데 8898μs
라인 4~5가 걸리고 서버는 요청 수신을 확인합니다. 걸린 시간은 5μs
5~6줄을 보면 스크립트 실행 시간이 60s1387μs로 PHP 스크립트와 일치함을 알 수 있습니다.
라인 6과 8에서는 서버가 http 응답을 보냅니다. 응답을 보내는 데 90166μs가 걸렸습니다.
7번째 줄은 서버 데몬이 적극적으로 연결을 닫는다는 것을 나타냅니다. 6행과 8행을 결합하면 http 응답이 전송되면 서버가 즉시 tcp 연결을 닫는 것을 보여줍니다. 7, 9, 10행은 90963μs가 소요되면서 tcp 연결이 순차적으로 닫히는 것을 보여줍니다. 여기서 소켓 리소스는 즉시 해제되지 않으며 실제로 해제되기 전에 2msl(60초)을 기다려야 한다는 점에 유의해야 합니다.
keepalive_timeout이 설정되지 않은 경우 소켓 리소스가 생성되고 해제되는 데 걸리는 시간은 tcp 연결 설정 + http 요청 전송 + php 스크립트 실행 + http 응답 전송 + tcp 연결 닫기 + 2msl임을 알 수 있습니다. (참고: 여기의 시간은 참고용으로만 사용할 수 있습니다. 구체적인 시간은 주로 네트워크 대역폭과 응답 크기에 따라 결정됩니다.)
2. keepalive_timeout 시간이 0보다 큰 경우, 즉 keep-alive가 활성화된 경우 TCP 연결의 수명주기. 분석을 용이하게 하기 위해 keepalive_timeout을 300초로 설정했습니다
#tcpdump -n host 218.1.57.236 and port 80
21:38:05.471129 ip 218.1.57.236.54049 > 222.73.211.215.http: s 1669618600:1669618600(0) win 65535 21:38:05.471140 ip 222.73.211.215.http > 218.1.57.236.54049: s 4166993862:4166993862(0) ack 1669618601 win 5840 21:38:05.481731 ip 218.1.57.236.54049 > 222.73.211.215.http: . ack 1 win 32768 21:38:05.481976 ip 218.1.57.236.54049 > 222.73.211.215.http: p 1:797(796) ack 1 win 32768 21:38:05.481985 ip 222.73.211.215.http > 218.1.57.236.54049: . ack 797 win 59 21:38:07.483626 ip 222.73.211.215.http > 218.1.57.236.54049: p 1:326(325) ack 797 win 59 21:38:07.747614 ip 218.1.57.236.54049 > 222.73.211.215.http: . ack 326 win 32605 21:43:07.448454 ip 222.73.211.215.http > 218.1.57.236.54049: f 326:326(0) ack 797 win 59 21:43:07.560316 ip 218.1.57.236.54049 > 222.73.211.215.http: . ack 327 win 32605 21:43:11.759102 ip 218.1.57.236.54049 > 222.73.211.215.http: f 797:797(0) ack 327 win 32605 21:43:11.759111 ip 222.73.211.215.http > 218.1.57.236.54049: . ack 798 win 59먼저 6~8번째 줄을 살펴보겠습니다. 마지막 예와 차이점은 서버 httpd 데몬이 응답을 보낸 후 적극적으로 TCP를 닫지 않았다는 것입니다. 즉시 연결됩니다.
라인 8과 라인 6을 결합하면 5분(300초) 후에 서버가 적극적으로 TCP 연결을 닫는 것을 볼 수 있습니다. 이번 시간은 우리가 keepalive_timeout을 설정한 시간과 정확히 같습니다.
keepalive_timout 시간을 설정하면 소켓 설정부터 해제까지 걸리는 시간이 keepalive_timeout 시간보다 길어지는 것을 알 수 있습니다.
3. keepalive_timeout 시간이 0보다 크고 동일한 TCP 연결에서 여러 http 응답이 전송되는 경우. 여기서는 분석을 용이하게 하기 위해 keepalive_timeout을 180초로 설정했습니다. 이 테스트를 통해 keepalive_timeout이 첫 번째 응답 끝에서 타이밍을 시작하는지 아니면 마지막 응답 끝에서 타이밍을 시작하는지 파악하려고 합니다. 테스트 결과 후자인 것으로 확인되었습니다. 여기서는 120초마다 요청을 보냈고 tcp 연결을 통해 3번의 요청을 보냈습니다.
# tcpdump -n host 218.1.57.236 and port 80
22:43:57.102448 ip 218.1.57.236.49955 > 222.73.211.215.http: s 4009392741:4009392741(0) win 65535 22:43:57.102527 ip 222.73.211.215.http > 218.1.57.236.49955: s 4036426778:4036426778(0) ack 4009392742 win 5840 22:43:57.111337 ip 218.1.57.236.49955 > 222.73.211.215.http: . ack 1 win 3276822:43:57.111522 ip 218.1.57.236.49955 > 222.73.211.215.http: p 1:797(796) ack 1 win 32768 22:43:57.111530 ip 222.73.211.215.http > 218.1.57.236.49955: . ack 797 win 59 22:43:59.114663 ip 222.73.211.215.http > 218.1.57.236.49955: p 1:326(325) ack 797 win 59 22:43:59.350143 ip 218.1.57.236.49955 > 222.73.211.215.http: . ack 326 win 3260522:45:59.226102 ip 218.1.57.236.49955 > 222.73.211.215.http: p 1593:2389(796) ack 650 win 32443 22:45:59.226109 ip 222.73.211.215.http > 218.1.57.236.49955: . ack 2389 win 83 22:46:01.227187 ip 222.73.211.215.http > 218.1.57.236.49955: p 650:974(324) ack 2389 win 83 22:46:01.450364 ip 218.1.57.236.49955 > 222.73.211.215.http: . ack 974 win 3228122:47:57.377707 ip 218.1.57.236.49955 > 222.73.211.215.http: p 3185:3981(796) ack 1298 win 32119 22:47:57.377714 ip 222.73.211.215.http > 218.1.57.236.49955: . ack 3981 win 108 22:47:59.379496 ip 222.73.211.215.http > 218.1.57.236.49955: p 1298:1622(324) ack 3981 win 108 22:47:59.628964 ip 218.1.57.236.49955 > 222.73.211.215.http: . ack 1622 win 3276822:50:59.358537 ip 222.73.211.215.http > 218.1.57.236.49955: f 1622:1622(0) ack 3981 win 108 22:50:59.367911 ip 218.1.57.236.49955 > 222.73.211.215.http: . ack 1623 win 32768 22:50:59.686527 ip 218.1.57.236.49955 > 222.73.211.215.http: f 3981:3981(0) ack 1623 win 32768 22:50:59.686531 ip 222.73.211.215.http > 218.1.57.236.49955: . ack 3982 win 108
第一组,三个ip包表示tcp三次握手建立连接,由浏览器建立。
第二组,发送第一次http请求并且得到响应,服务端守护进程输出响应之后,并没马上主动关闭tcp连接。而是启动keepalive_timout计时。
第三组,2分钟后,发送第二次http请求并且得到响应,同样服务端守护进程也没有马上主动关闭tcp连接,重新启动keepalive_timout计时。
第四组,又2分钟后,发送了第三次http请求并且得到响应。服务器守护进程依然没有主动关地闭tcp连接(距第一次http响应有4分钟了,大于keepalive_timeout值),而是重新启动了keepalive_timout计时。
第五组,跟最后一个响应keepalive_timeout(180s)内,守护进程再没有收到请求。计时结束,服务端守护进程主动关闭连接。4次挥手后,服务端进入time_wait状态。
这说明,当设定了keepalive_timeout,一个socket由建立到释放,需要时间是:tcp建立 + (最后一个响应时间 – 第一个请求时间) + tcp关闭 + 2msl。红色加粗表示每一次请求发送时间、每一次请求脚本执行时间、每一次响应发送时间,还有两两请求相隔时间。进一步测试,正在关闭或者 time_wait状态的tcp连接,不能传输http请求和响应。即,当一个连接结束keepalive_timeout计时,服务端守护进程发送第一 个fin标志ip包后,该连接不能再使用了。
http keep-alive与tcp keep-alive
http keep-alive与tcp keep-alive,不是同一回事,意图不一样。http keep-alive是为了让tcp活得更久一点,以便在同一个连接上传送多个http,提高socket的效率。而tcp keep-alive是tcp的一种检测tcp连接状况的保鲜机制。tcp keep-alive保鲜定时器,支持三个系统内核配置参数:
echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time echo 15 > /proc/sys/net/ipv4/tcp_keepalive_intvl echo 5 > /proc/sys/net/ipv4/tcp_keepalive_probes
keepalive是tcp保鲜定时器,当网络两端建立了tcp连接之后,闲置idle(双方没有任何数据流发送往来)了 tcp_keepalive_time后,服务器内核就会尝试向客户端发 送侦测包,来判断tcp连接状况(有可能客户端崩溃、强制关闭了应用、主机不可达等等)。如果没有收到对方的回答(ack包),则会在 tcp_keepalive_intvl后再次尝试发送侦测包,直到收到对对方的ack,如果一直没有收到对方的ack,一共会尝试 tcp_keepalive_probes次,每次的间隔时间在这里分别是15s, 30s, 45s, 60s, 75s。如果尝试tcp_keepalive_probes,依然没有收到对方的ack包,则会丢弃该tcp连接。tcp连接默认闲置时间是2小时,一般 设置为30分钟足够了。也就是说,仅当nginx的keepalive_timeout值设置高于tcp_keepalive_time,并且距此tcp连接传输的最后一 个http响应,经过了tcp_keepalive_time时间之后,操作系统才会发送侦测包来决定是否要丢弃这个tcp连接。一般不会出现这种情况, 除非你需要这样做。
keep-alive与time_wait
使用http keep-alvie,可以减少服务端time_wait数量(因为由服务端httpd守护进程主动关闭连接)。道理很简单,相较而言,启用keep-alive,建立的tcp连接更少了,自然要被关闭的tcp连接也相应更少了。
위 내용은 Nginx에서 HTTP Keepalive를 구성하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

Nginx와 Apache는 성능, 확장 성 및 효율성 측면에서 고유 한 장점과 단점을 가진 강력한 웹 서버입니다. 1) NGINX는 정적 컨텐츠를 처리하고 역전 프록시를 처리 할 때 잘 수행되며 동시 동시성 시나리오에 적합합니다. 2) Apache는 동적 컨텐츠를 처리 할 때 더 나은 성능을 발휘하며 풍부한 모듈 지원이 필요한 프로젝트에 적합합니다. 서버 선택은 프로젝트 요구 사항 및 시나리오에 따라 결정해야합니다.

Nginx는 높은 동시 요청을 처리하는 데 적합한 반면 Apache는 복잡한 구성 및 기능 확장이 필요한 시나리오에 적합합니다. 1.NGINX는 이벤트 중심의 비 블로킹 아키텍처를 채택하며, 대결 환경에 적합합니다. 2. Apache는 프로세스 또는 스레드 모델을 채택하여 복잡한 구성 요구에 적합한 풍부한 모듈 생태계를 제공합니다.

Nginx는 웹 사이트 성능, 보안 및 확장 성을 향상시키는 데 사용될 수 있습니다. 1) 리버스 프록시 및로드 밸런서로서 Nginx는 백엔드 서비스를 최적화하고 트래픽을 공유 할 수 있습니다. 2) 이벤트 중심 및 비동기 아키텍처를 통해 Nginx는 높은 동시 연결을 효율적으로 처리합니다. 3) 구성 파일을 사용하면 정적 파일 서비스 및로드 밸런싱과 같은 규칙을 유연하게 정의 할 수 있습니다. 4) 최적화 제안에는 GZIP 압축 활성화, 캐시 사용 및 작업자 프로세스 조정이 포함됩니다.

NginxUnit은 여러 프로그래밍 언어를 지원하며 모듈 식 디자인을 통해 구현됩니다. 1. 언어 모듈로드 : 구성 파일에 따라 해당 모듈을로드합니다. 2. 응용 프로그램 시작 : 호출 언어가 실행될 때 응용 프로그램 코드를 실행합니다. 3. 요청 처리 : 응용 프로그램 인스턴스로 요청을 전달하십시오. 4. 응답 반환 : 처리 된 응답을 클라이언트에 반환합니다.

Nginx와 Apache는 고유 한 장점과 단점이 있으며 다른 시나리오에 적합합니다. 1.NGINX는 높은 동시성 및 낮은 자원 소비 시나리오에 적합합니다. 2. Apache는 복잡한 구성 및 풍부한 모듈이 필요한 시나리오에 적합합니다. 핵심 기능, 성능 차이 및 모범 사례를 비교하면 요구에 가장 적합한 서버 소프트웨어를 선택할 수 있습니다.

질문 : nginx를 시작하는 방법? 답변 : nginx 스타트 업 설치 nginx verification nginx is nginx 시작 다른 시작 옵션을 자동으로 시작합니다.

nginx가 시작되었는지 확인하는 방법 : 1. 명령 줄을 사용하십시오 : SystemCTL 상태 nginx (linux/unix), netstat -ano | Findstr 80 (Windows); 2. 포트 80이 열려 있는지 확인하십시오. 3. 시스템 로그에서 nginx 시작 메시지를 확인하십시오. 4. Nagios, Zabbix 및 Icinga와 같은 타사 도구를 사용하십시오.

Nginx 서비스를 종료하려면 다음 단계를 따르려면 다음 단계를 결정합니다. Red Hat/Centos (SystemCTL 상태 NGINX) 또는 Debian/Ubuntu (서비스 NGINX 상태) 서비스 중지 : Red Hat/Centos (SystemCTL STOP NGINX) 또는 DEBIAN/UBUNTU (서비스 NGINX STOP) DIA AUTAL STARTUP (옵션) : RED HAT/CENTOS (SystemCTLED) 또는 DEBIAN/UBUNT (SystemCTLED). (Syst


핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

Dreamweaver Mac版
시각적 웹 개발 도구

Atom Editor Mac 버전 다운로드
가장 인기 있는 오픈 소스 편집기

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

MinGW - Windows용 미니멀리스트 GNU
이 프로젝트는 osdn.net/projects/mingw로 마이그레이션되는 중입니다. 계속해서 그곳에서 우리를 팔로우할 수 있습니다. MinGW: GCC(GNU Compiler Collection)의 기본 Windows 포트로, 기본 Windows 애플리케이션을 구축하기 위한 무료 배포 가능 가져오기 라이브러리 및 헤더 파일로 C99 기능을 지원하는 MSVC 런타임에 대한 확장이 포함되어 있습니다. 모든 MinGW 소프트웨어는 64비트 Windows 플랫폼에서 실행될 수 있습니다.
