wget을 사용하여 몇 가지 테스트를 시도하고 있으며 HTTPS 페이지가 동일한 서버의 http보다 wget에로드되는 데 중요하다는 것을 알게되었습니다. 이것은 어떤 네트워크 차이와도 관련이없는 것처럼 보입니다. 이름 해석 wget 전에는 약 5 초가 더 걸립니다. 아무도 도와 줄 수 있습니까? 어떻게 이것을 극복 할 수 있습니까? 네트워크 성능을 평가할 때 -p 및 -H 옵션을 사용하여 wget을 사용하고 싶었습니다.WGET - HTTPS 대 HTTP = HTTPS 느림

[email protected] ~ $ wget -V 
GNU Wget 1.13.4 built on linux-gnueabihf. 

+digest +https +ipv6 +iri +large-file +nls -ntlm +opie +ssl/gnutls 

Wgetrc: 
    /etc/wgetrc (system) 
Locale: /usr/share/locale 
Compile: gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/etc/wgetrc" 
    -DLOCALEDIR="/usr/share/locale" -I. -I../lib -I../lib 
    -D_FORTIFY_SOURCE=2 -Iyes/include -g -O2 -fstack-protector 
    --param=ssp-buffer-size=4 -Wformat -Werror=format-security 
    -DNO_SSLv2 -D_FILE_OFFSET_BITS=64 -g -Wall 
Link: gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
    -Werror=format-security -DNO_SSLv2 -D_FILE_OFFSET_BITS=64 -g -Wall 
    -Wl,-z,relro -Lyes/lib -lgnutls -lgcrypt -lgpg-error -lz -lidn -lrt 
    ftp-opie.o gnutls.o ../lib/libgnu.a 

Copyright (C) 2009 Free Software Foundation, Inc. 
License GPLv3+: GNU GPL version 3 or later 
<http://www.gnu.org/licenses/gpl.html>. 
This is free software: you are free to change and redistribute it. 
There is NO WARRANTY, to the extent permitted by law. 

Originally written by Hrvoje Niksic <[email protected]>. 
Please send bug reports and questions to <[email protected]>. 
[email protected] ~ $ time wget -d -v --no-check-certificate --delete-after -4 http://www.google.pt 2>&1 | awk '{ print strftime("%Y-%m-%d %H:%M:%S"), $0; fflush(); }' 
2015-02-07 01:10:57 Setting --verbose (verbose) to 1 
2015-02-07 01:10:57 Setting --check-certificate (checkcertificate) to 0 
2015-02-07 01:10:57 Setting --delete-after (deleteafter) to 1 
2015-02-07 01:10:57 Setting --inet4-only (inet4only) to 1 
2015-02-07 01:10:57 DEBUG output created by Wget 1.13.4 on linux-gnueabihf. 
2015-02-07 01:10:57 
2015-02-07 01:10:57 URI encoding = `UTF-8' 
2015-02-07 01:10:57 --2015-02-07 01:10:57-- http://www.google.pt/ 
2015-02-07 01:10:57 Resolving www.google.pt (www.google.pt)... 213.30.5.52, 213.30.5.24, 213.30.5.18, ... 
2015-02-07 01:10:57 Caching www.google.pt => 213.30.5.52 213.30.5.24 213.30.5.18 213.30.5.25 213.30.5.59 213.30.5.31 213.30.5.45 213.30.5.46 213.30.5.39 213.30.5.53 213.30.5.32 213.30.5.38 
2015-02-07 01:10:57 Connecting to www.google.pt (www.google.pt)|213.30.5.52|:80... connected. 
2015-02-07 01:10:57 Created socket 3. 
2015-02-07 01:10:57 Releasing 0x003b8040 (new refcount 1). 
2015-02-07 01:10:57 
2015-02-07 01:10:57 ---request begin--- 
2015-02-07 01:10:57 GET/HTTP/1.1 
2015-02-07 01:10:57 User-Agent: Wget/1.13.4 (linux-gnueabihf) 
2015-02-07 01:10:57 Accept: */* 
2015-02-07 01:10:57 Host: www.google.pt 
2015-02-07 01:10:57 Connection: Keep-Alive 
2015-02-07 01:10:57 
2015-02-07 01:10:57 ---request end--- 
2015-02-07 01:10:58 HTTP request sent, awaiting response... 
2015-02-07 01:10:58 ---response begin--- 
2015-02-07 01:10:58 HTTP/1.1 200 OK 
2015-02-07 01:10:58 Date: Sat, 07 Feb 2015 01:10:58 GMT 
2015-02-07 01:10:58 Expires: -1 
2015-02-07 01:10:58 Cache-Control: private, max-age=0 
2015-02-07 01:10:58 Content-Type: text/html; charset=ISO-8859-1 
2015-02-07 01:10:58 Set-Cookie: PREF=ID=98608883e4031983:FF=0:TM=1423271458:LM=1423271458:S=BnwaLDxFbjCUyPnF; expires=Mon, 06-Feb-2017 01:10:58 GMT; path=/; domain=.google.pt 
2015-02-07 01:10:58 Set-Cookie: NID=67=AkXpY2nJPDDcH7xKJkslxdCtflnhOZJiNwZdu4YBAIc2FnjIZIAYHzFuln5boxiOHq1WWBdbcTnLXwPqOrfxOxkLXtO2U5UAVBCU0nVcgyC61_YLZLXGR0Fmdi9M_fIp; expires=Sun, 09-Aug-2015 01:10:58 GMT; path=/; domain=.google.pt; HttpOnly 
2015-02-07 01:10:58 P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info." 
2015-02-07 01:10:58 Server: gws 
2015-02-07 01:10:58 X-XSS-Protection: 1; mode=block 
2015-02-07 01:10:58 X-Frame-Options: SAMEORIGIN 
2015-02-07 01:10:58 Alternate-Protocol: 80:quic,p=0.02 
2015-02-07 01:10:58 Accept-Ranges: none 
2015-02-07 01:10:58 Vary: Accept-Encoding 
2015-02-07 01:10:58 Transfer-Encoding: chunked 
2015-02-07 01:10:58 
2015-02-07 01:10:58 ---response end--- 
2015-02-07 01:10:58 200 OK 
2015-02-07 01:10:58 cdm: 1 2 3 4 5 6 7 8 
2015-02-07 01:10:58 Stored cookie google.pt -1 (ANY)/<permanent> <insecure> [expiry 2017-02-06 01:10:58] PREF ID=98608883e4031983:FF=0:TM=1423271458:LM=1423271458:S=BnwaLDxFbjCUyPnF 
2015-02-07 01:10:58 cdm: 1 2 3 4 5 6 7 8 
2015-02-07 01:10:58 Stored cookie google.pt -1 (ANY)/<permanent> <insecure> [expiry 2015-08-09 02:10:58] NID 67=AkXpY2nJPDDcH7xKJkslxdCtflnhOZJiNwZdu4YBAIc2FnjIZIAYHzFuln5boxiOHq1WWBdbcTnLXwPqOrfxOxkLXtO2U5UAVBCU0nVcgyC61_YLZLXGR0Fmdi9M_fIp 
2015-02-07 01:10:58 Registered socket 3 for persistent reuse. 
2015-02-07 01:10:58 URI content encoding = `ISO-8859-1' 
2015-02-07 01:10:58 Length: unspecified [text/html] 
2015-02-07 01:10:58 Saving to: `index.html' 
2015-02-07 01:10:58 
2015-02-07 01:10:58  0K .......... .......          17.6M=0.001s 
2015-02-07 01:10:58 
2015-02-07 01:10:58 2015-02-07 01:10:58 (17.6 MB/s) - `index.html' saved [18301] 
2015-02-07 01:10:58 
2015-02-07 01:10:58 Removing file due to --delete-after in main(): 
2015-02-07 01:10:58 Removing index.html. 

real 0m0.350s 
user 0m0.038s 
sys  0m0.027s 
[email protected] ~ $ time wget -d -v --no-check-certificate --delete-after -4 https://www.google.pt 2>&1 | awk '{ print strftime("%Y-%m-%d %H:%M:%S"), $0; fflush(); }' 
2015-02-07 01:11:01 Setting --verbose (verbose) to 1 
2015-02-07 01:11:01 Setting --check-certificate (checkcertificate) to 0 
2015-02-07 01:11:01 Setting --delete-after (deleteafter) to 1 
2015-02-07 01:11:01 Setting --inet4-only (inet4only) to 1 
2015-02-07 01:11:01 DEBUG output created by Wget 1.13.4 on linux-gnueabihf. 
2015-02-07 01:11:01 
2015-02-07 01:11:01 URI encoding = `UTF-8' 
2015-02-07 01:11:01 --2015-02-07 01:11:01-- https://www.google.pt/ 
2015-02-07 01:11:06 Resolving www.google.pt (www.google.pt)... 213.30.5.25, 213.30.5.53, 213.30.5.38, ... 
2015-02-07 01:11:06 Caching www.google.pt => 213.30.5.25 213.30.5.53 213.30.5.38 213.30.5.32 213.30.5.24 213.30.5.46 213.30.5.39 213.30.5.18 213.30.5.52 213.30.5.31 213.30.5.59 213.30.5.45 
2015-02-07 01:11:06 Connecting to www.google.pt (www.google.pt)|213.30.5.25|:443... connected. 
2015-02-07 01:11:06 Created socket 4. 
2015-02-07 01:11:06 Releasing 0x00b53d48 (new refcount 1). 
2015-02-07 01:11:06 
2015-02-07 01:11:06 ---request begin--- 
2015-02-07 01:11:06 GET/HTTP/1.1 
2015-02-07 01:11:06 User-Agent: Wget/1.13.4 (linux-gnueabihf) 
2015-02-07 01:11:06 Accept: */* 
2015-02-07 01:11:06 Host: www.google.pt 
2015-02-07 01:11:06 Connection: Keep-Alive 
2015-02-07 01:11:06 
2015-02-07 01:11:06 ---request end--- 
2015-02-07 01:11:06 HTTP request sent, awaiting response... 
2015-02-07 01:11:06 ---response begin--- 
2015-02-07 01:11:06 HTTP/1.1 200 OK 
2015-02-07 01:11:06 Date: Sat, 07 Feb 2015 01:11:06 GMT 
2015-02-07 01:11:06 Expires: -1 
2015-02-07 01:11:06 Cache-Control: private, max-age=0 
2015-02-07 01:11:06 Content-Type: text/html; charset=ISO-8859-1 
2015-02-07 01:11:06 Set-Cookie: PREF=ID=579b1dd2360c9122:FF=0:TM=1423271466:LM=1423271466:S=9zOSotidcZWjJfXX; expires=Mon, 06-Feb-2017 01:11:06 GMT; path=/; domain=.google.pt 
2015-02-07 01:11:06 Set-Cookie: NID=67=Jetj6llJijt09db9ekqGS6cBo3DE0CDqfQkp9Sh8xtLyYnNGU5zHoMED0whNkToP_w6mk6-oLTSRVdYIDekUEZH02oBYQPQhHmhpQzENI08zGNg9Jxn4EkXTIVApLCAG; expires=Sun, 09-Aug-2015 01:11:06 GMT; path=/; domain=.google.pt; HttpOnly 
2015-02-07 01:11:06 P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info." 
2015-02-07 01:11:06 Server: gws 
2015-02-07 01:11:06 X-XSS-Protection: 1; mode=block 
2015-02-07 01:11:06 X-Frame-Options: SAMEORIGIN 
2015-02-07 01:11:06 Accept-Ranges: none 
2015-02-07 01:11:06 Vary: Accept-Encoding 
2015-02-07 01:11:06 Transfer-Encoding: chunked 
2015-02-07 01:11:06 
2015-02-07 01:11:06 ---response end--- 
2015-02-07 01:11:06 200 OK 
2015-02-07 01:11:06 cdm: 1 2 3 4 5 6 7 8 
2015-02-07 01:11:06 Stored cookie google.pt -1 (ANY)/<permanent> <insecure> [expiry 2017-02-06 01:11:06] PREF ID=579b1dd2360c9122:FF=0:TM=1423271466:LM=1423271466:S=9zOSotidcZWjJfXX 
2015-02-07 01:11:06 cdm: 1 2 3 4 5 6 7 8 
2015-02-07 01:11:06 Stored cookie google.pt -1 (ANY)/<permanent> <insecure> [expiry 2015-08-09 02:11:06] NID 67=Jetj6llJijt09db9ekqGS6cBo3DE0CDqfQkp9Sh8xtLyYnNGU5zHoMED0whNkToP_w6mk6-oLTSRVdYIDekUEZH02oBYQPQhHmhpQzENI08zGNg9Jxn4EkXTIVApLCAG 
2015-02-07 01:11:06 Registered socket 4 for persistent reuse. 
2015-02-07 01:11:06 URI content encoding = `ISO-8859-1' 
2015-02-07 01:11:06 Length: unspecified [text/html] 
2015-02-07 01:11:06 Saving to: `index.html' 
2015-02-07 01:11:06 
2015-02-07 01:11:06  0K .......... .......          670K=0.03s 
2015-02-07 01:11:06 
2015-02-07 01:11:06 2015-02-07 01:11:06 (670 KB/s) - `index.html' saved [18319] 
2015-02-07 01:11:06 
2015-02-07 01:11:06 Removing file due to --delete-after in main(): 
2015-02-07 01:11:06 Removing index.html. 

real 0m5.371s 
user 0m4.083s 
sys  0m0.280s

컬에서 차이가 그렇게 큰 ... 세션 키를 설정해야합니다 때문에 SSL/TSL 설정과 관련된 약간의 오버 헤드가있다

[email protected] ~ $ curl -V 
curl 7.26.0 (arm-unknown-linux-gnueabihf) libcurl/7.26.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.2 librtmp/2.3 
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp 
Features: Debug GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP 
[email protected] ~ $ time curl -s http:///www.google.pt > /dev/null 

real 0m0.140s 
user 0m0.056s 
sys  0m0.034s 
[email protected] ~ $ time curl -s https:///www.google.pt > /dev/null 

real 0m0.294s 
user 0m0.060s 
sys  0m0.031s

출처

2015-02-07 husvar

은 왜 그냥 컬을 사용할 수 있습니까? –

실제로 -p 및 -H 옵션을 사용하려고하기 때문에. 나는 컬이 이것을지지하지 않는다. – husvar

wget 개발자들과 몇 가지 테스트와 토론을 한 결과, gnutls 라이브러리 때문이라는 결론에 도달했습니다. 대신 wget이 openssl로 컴파일되면 동작은 컬과 비슷합니다. – husvar

wget 개발자들과 몇 가지 테스트와 토론을 한 결과, 이것은 gnutls 라이브러리 때문인 것으로 결론을 냈습니다. 대신 wget이 openssl로 컴파일되면 동작은 컬과 비슷합니다.

출처

2015-02-21 11:10:00 husvar

는 그러나이 보이지 않는다 그것은 무시할 수있는 경향이 있으므로, 그것이 진짜 이유가 될지는 모르겠지만 결코 알지 못합니다.

출처

2015-02-07 01:23:01

어떻게이 문제를 해결할 수 있습니까?

수 없습니다.

HTTP와 HTTPS의 차이점은 후자가 SSL/TLS를 사용하여 연결을 보호한다는 점입니다. SSL/TLS 상당한 오버 헤드가 있습니다

에서 그래서 그 (적어도) 클라이언트가 서버가 사기꾼 아니라는 것을 확인할 수 있습니다하기 등등, 클라이언트와 서버 인증서를 교환, 시작합니다.

시작 협상은 다수의 클라이언트 < -> 서버 메시지 교환을 수반합니다. TCP/IP 레벨 연결에 상당한 대기 시간이 있으면 이는 현저한 지연으로 나타납니다.
일단 연결이 설정되면 연결시 데이터가 송신시 암호화되고 수신시 암호가 해독됩니다. 내가 HTTPS에 대한 실제적인 대안이 없다고 생각

는 정기적으로, 현재 세대의 웹 서버에 안전하게 이야기 할 것입니다. 나는 그것이 "차세대"HTTP로 변화한다고 생각하지 않는다. 즉 HTTP/2입니다.

속도를 높이려면 (HTTP/1.1 또는 HTTP/2) 할 수있는 유일한 방법은 여러 GET에 대해 "지속적인 연결"을 재사용하는 것입니다. SSL/TLS 협상은 연결이 설정 될 때만 발생합니다. 그러나 지속적인 연결은 "단일 샷"유스 케이스에서는 도움이되지 않습니다. 예 : wget 또는 curl을 사용하여 하나의 파일을 가져 오는 경우

출처

2015-02-07 01:25:15

실제로 HTTP/1.1을 사용하는 경우에도 영구 연결을 사용하고 HTTPS를 통해 여러 요청에 동일한 연결을 재사용 할 수 있습니다. SSL/TLS 협상은 새 연결을 만들 때만 발생해야합니다. – darnir

@damir - 감사합니다. (실제로, 나는 그것을 알고 있었다 : ...-)) –

하지만 연결이 시작되기 전에 (실제로 이름 확인 전에) 5 초의 오버 헤드가 발생하는 것처럼 보인다 ... 이것이 의미가 있나? – husvar

어떻게 극복 할 수 있습니까?

this은 GNU Wget에는 문제가되지 않습니다. 나는 당신의 명령을 달렸다 :

$ time wget -d -v --no-check-certificate --delete-after -4 http://www.google.pt 2>&1 | awk '{ print strftime("%Y-%m-%d %H:%M:%S"), $0; fflush(); }' 
$ time wget -d -v --no-check-certificate --delete-after -4 https://www.google.pt 2>&1 | awk '{ print strftime("%Y-%m-%d %H:%M:%S"), $0; fflush(); }'

그리고 약 10 번씩 달렸다. 최종 결과? SSL/TSL 협상 프로토콜로 인해 시간의 차이가 미미했습니다. 이것은 GNU Wget의 행동에 대한 나의 기대와 잘 부합한다. 그렇다면 왜 그렇게 큰 차이를 보았습니까?https 버전에 대한 출력에서

살펴 보자 :

2015-02-07 01:11:01 Setting --verbose (verbose) to 1 
2015-02-07 01:11:01 Setting --check-certificate (checkcertificate) to 0 
2015-02-07 01:11:01 Setting --delete-after (deleteafter) to 1 
2015-02-07 01:11:01 Setting --inet4-only (inet4only) to 1 
2015-02-07 01:11:01 DEBUG output created by Wget 1.13.4 on linux-gnueabihf. 
2015-02-07 01:11:01 
2015-02-07 01:11:01 URI encoding = `UTF-8' 
2015-02-07 01:11:01 --2015-02-07 01:11:01-- https://www.google.pt/ 
2015-02-07 01:11:06 Resolving www.google.pt (www.google.pt)... 213.30.5.25, 213.30.5.53, 213.30.5.38, ... 
2015-02-07 01:11:06 Caching www.google.pt => 213.30.5.25 213.30.5.53 213.30.5.38 213.30.5.32 213.30.5.24 213.30.5.46 213.30.5.39 213.30.5.18 213.30.5.52 213.30.5.31 213.30.5.59 213.30.5.45 
2015-02-07 01:11:06 Connecting to www.google.pt (www.google.pt)|213.30.5.25|:443... connected. 
2015-02-07 01:11:06 Created socket 4. 
2015-02-07 01:11:06 Releasing 0x00b53d48 (new refcount 1). 
2015-02-07 01:11:06 
2015-02-07 01:11:06 ---request begin--- 
2015-02-07 01:11:06 GET/HTTP/1.1 
2015-02-07 01:11:06 User-Agent: Wget/1.13.4 (linux-gnueabihf) 
2015-02-07 01:11:06 Accept: */* 
2015-02-07 01:11:06 Host: www.google.pt 
2015-02-07 01:11:06 Connection: Keep-Alive 
2015-02-07 01:11:06 
2015-02-07 01:11:06 ---request end---

나는 단지를 Wget은 첫 번째 요청을 보낼 때까지 출력 고려했다. 이 시점에서 모든 사람이 주장하는 SSL/TSL 협상은 시간이 크게 늘어 났으며 시작조차하지 못했습니다. 그러나주의 깊게 살펴보면 시간은> 5 초입니다!

따라서이 동작은 확실히 HTTPS를 사용하는 오버 헤드로 인한 것이 아닙니다. 그래서, 그것은 무엇입니까? 다시 말하지만 출력을 자세히 살펴보십시오. 최대 시간이 지나간 줄은?

2015-02-07 01:11:01 --2015-02-07 01:11:01-- https://www.google.pt/ 
2015-02-07 01:11:06 Resolving www.google.pt (www.google.pt)... 213.30.5.25, 213.30.5.53, 213.30.5.38, ...

즉, 도메인 이름에서 IP 주소를 확인하는 데 약 5 초가 걸렸습니다. 그러나 DNS 해상도는 Wget이 처리하는 것이 아닙니다. Wget은 시스템에 IP 주소를 요청합니다. 이것은 파일 host.c:329에서 볼 수있다 : 정말 귀하의 경우에는 무슨 일이 있었는지

따라서

static void 
gethostbyname_with_timeout_callback (void *arg) 
{ 
    struct ghbnwt_context *ctx = (struct ghbnwt_context *)arg; 
    ctx->hptr = gethostbyname (ctx->host_name); 
}

는 시스템이 호스트 이름을 해결하기 위해 몇 가지 여분의 시간이 걸렸이었다. 이것은 여러 가지 이유로 발생할 수 있습니다. 그러나 테스트를 여러 번 실행하는 대신 성급한 일반화로 넘어 갔고 단순히 Wget이 HTTPS를 매우 천천히 수행한다고 가정했습니다.

출처

2015-02-07 02:14:37 darnir

문제는 해결 중이 아닌 "해결 ...."행이 나타날 때까지 5 초가 소비되었음을 나타냅니다. 이 지연은 항상 5 초입니다. 그것은 이름 해석 전에 soem 작업과 관련이있는 것 같습니다 ... – husvar

물론입니다. 이는 컴파일러 및 라이브러리 최적화로 인해 발생합니다. 최신 컴파일러는 성능을 향상시키기 위해 코드를 최적화하고 인쇄 문을 약간 옮깁니다. 그 위에, printf()는 전체 라인의 출력을 버퍼하는 것으로 알려져있다.IP 주소는 "Resolving ..."과 같은 행에 인쇄되기 때문에 출력이 표준 출력으로 플러시되지 않았기 때문에 출력이 표시되지 않을 수도 있습니다. (stderr가 정확해야합니다) – darnir

호스트 파일에 이것을 추가하여 확인합니다. 그러나 이것은 https에서만 발생하며 https와 http 사이의 이름 바꾸기에는 차이가 없습니다. – husvar

컴퓨터가 IPv6 DNS 검색을 시도하고 있는데 제대로 구성되지 않았기 때문에 실패합니다. 시간 초과 후 IPv4로 다시 떨어지고 연결이 성공합니다. 이것이 문제가되는 경우 IPv6 구성을 수정하거나 IPv6을 완전히 비활성화해야합니다.

이 이론을 테스트하려면 "ping6"을 사용하여 연결하려는 호스트를 핑 (ping)하십시오. 내 생각 엔 "ping"이 성공하는 동안 "ping6"이 실패합니다.

어떻게 테스트하는 :

[email protected]:~$ ping6 www.google.pt 
PING www.google.pt(ord30s26-in-x03.1e100.net) 56 data bytes 
64 bytes from ord30s26-in-x03.1e100.net: icmp_seq=1 ttl=53 time=19.5 ms 
64 bytes from ord30s26-in-x03.1e100.net: icmp_seq=2 ttl=53 time=18.3 ms 
^C 
--- www.google.pt ping statistics --- 
2 packets transmitted, 2 received, 0% packet loss, time 1001ms 
rtt min/avg/max/mdev = 18.342/18.970/19.599/0.643 ms 
[email protected]:~$ ping www.google.pt 
PING www.google.pt (216.58.192.227) 56(84) bytes of data. 
64 bytes from ord30s26-in-f3.1e100.net (216.58.192.227): icmp_seq=1 ttl=54 time=19.0 ms 
64 bytes from ord30s26-in-f3.1e100.net (216.58.192.227): icmp_seq=2 ttl=54 time=18.3 ms

출처

2016-03-24 21:23:30

WGET - HTTPS 대 HTTP = HTTPS 느림

답변

어떻게 테스트하는 :

관련 문제