ஆல் HTTP என்றால் என்ன? சர்வர் நிர்வாகிகளுக்கான முழு வழிகாட்டி
HTTP முறைகள், status codes, மற்றும் headers எவ்வாறு செயல்படுகின்றன என்பதை அறியுங்கள். Nginx logs, HTTP/3, மற்றும் TLS ஆகியவற்றின் முக்கியத்துவத்தை இந்த வழிகாட்டி விளக்குகிறது.
HTTP என்றால் என்ன?
HTTP (hypertext transfer protocol) என்பது ஒரு client மற்றும் web server ஆகியவை தகவல்களைக் கோருவதற்கும், பதிலளிப்பதற்கும் பயன்படுத்தும் விதிகளின் தொகுப்பாகும். Client ஒரு கோரிக்கையை (request) அனுப்புகிறது: இதில் GET போன்ற ஒரு method, /pricing போன்ற ஒரு path, protocol version, headers பட்டியல் மற்றும் சில நேரங்களில் ஒரு body ஆகியவை அடங்கும். Server இதற்கு 200 போன்ற ஒரு status code மூலம் பதிலளிக்கிறது; அதைத் தொடர்ந்து server-ன் சொந்த headers மற்றும் பொதுவாக ஒரு body ஆகியவை இருக்கும். உங்கள் server-ல் நடக்கும் ஒவ்வொரு page view மற்றும் ஒவ்வொரு API (application programming interface) அழைப்பும் இத்தகைய பரிமாற்றங்களின் தொடர்ச்சியே ஆகும்.
HTTP எந்தவொரு நிலையையும் (state) தானாகச் சேமிப்பதில்லை. ஒரு நொடிக்கு முன்பு நீங்கள் என்ன கேட்டீர்கள் என்பதை server நினைவில் கொள்வதில்லை. எனவே, login session போன்ற நினைவகம் போலச் செயல்படும் எந்தவொரு அம்சமும் ஒவ்வொரு கோரிக்கையிலும் ஒரு header-ஆகவே கொண்டு செல்லப்படுகிறது. இந்த ஒரு பண்புதான் பின்வருவனவற்றில் பலவற்றிற்கு விளக்கமாக அமைகிறது: caching என்பது முழுமையாக header-ஐ அடிப்படையாகக் கொண்டது, மேலும் ஒரு load balancer உங்கள் அடுத்த கோரிக்கையை வேறொரு backend-க்கு மாற்றினாலும் எந்தப் பாதிப்பும் ஏற்படாது.
கீழே கொடுக்கப்பட்டுள்ள அனைத்தும், உங்கள் access log மற்றும் nginx config-ல் இந்த மாதிரி server பக்கத்திலிருந்து எவ்வாறு அமைகிறது என்பதைக் காட்டுகிறது.
ஒரு raw request மற்றும் response, விளக்கங்களுடன்
முழுமையான HTTP/1.1 request ஒன்று கீழே கொடுக்கப்பட்டுள்ளது. தலைப்புகள் (headers) ஒரு காலி வரியுடன் முடிவடையும், அந்த வரிக்குப்பின் வருபவை body எனப்படும். ஒரு GET பொதுவாக body-ஐக் கொண்டிருக்காது.
GET /pricing HTTP/1.1
Host: example.com
User-Agent: curl/8.5.0
Accept: */*
Accept-Encoding: gzipGETஎன்பது method, இது நீங்கள் என்ன செய்ய விரும்புகிறீர்கள் என்பதைத் தெரிவிக்கும்.GETதகவலைப் படிக்கிறது,POSTதகவலை அனுப்புகிறது,PUTமாற்றீடு செய்கிறது,DELETEநீக்குகிறது,HEADஒருGET-ன் தலைப்புகளை மட்டும், body இல்லாமல் கேட்கிறது./pricingஎன்பது path. Hostname என்பது request வரியின் ஒரு பகுதி அல்ல, அதனால்தான் அடுத்த தலைப்பு தேவைப்படுகிறது.HTTP/1.1என்பது client பயன்படுத்தும் protocol version.Host: example.comஎன்பது client அணுக விரும்பும் site-ன் பெயர். HTTP/1.1-க்கு இது கட்டாயம், எனவே hostname இல்லாத request-க்கு nginx400 Bad Requestமூலம் பதிலளிக்கும்.- மற்றவை விருப்பத்தேர்வுகள்.
Accept-Encoding: gzipஎன்பது client-ஆல் தகவலைச் சுருக்கத்தை நீக்க (decompress) முடியும் என்பதைக் குறிக்கிறது, எனவே server body-ஐச் சுருக்கி (compress) அனுப்ப அனுமதிக்கப்படுகிறது.
Response-ம் இதே அமைப்பைக் கொண்டது, ஆனால் மேலே ஒரு status வரி இருக்கும்.
HTTP/1.1 200 OK
Date: Thu, 06 Aug 2026 09:12:44 GMT
Server: nginx
Content-Type: text/html; charset=utf-8
Content-Length: 5310
Cache-Control: public, max-age=300
<!doctype html>...200 OKஎன்பது status code மற்றும் அதன் reason phrase. இதில் code மட்டுமே முக்கியமானது. Phrase என்பது அலங்காரத்திற்காக மட்டுமே, client-கள் இதைப் புறக்கணிக்கும்.Content-Typeஎன்பது பின்வரும் bytes-ஐ எவ்வாறு கையாள வேண்டும் என்று client-க்குத் தெரிவிக்கும்.Content-Lengthஎன்பது body-ன் அளவு (bytes-ல்), இதன் மூலம் body எங்கு முடிகிறது என்பதை client அறியும். அளவு முன்கூட்டியே தெரியவில்லை என்றால், serverTransfer-Encoding: chunked-ஐ அனுப்பி, பூஜ்ஜிய அளவுள்ள chunk மூலம் முடிவைக் குறிக்கும்.Cache-Controlஎன்பது இந்த response-ஐ browser மற்றும் இடையில் உள்ள cache எவ்வளவு காலம் வைத்திருக்கலாம் என்று தெரிவிக்கும்.- தலைப்புகளுக்குப் பின் உள்ள காலி வரி, தலைப்புகளையும் body-யையும் பிரிக்கிறது; இது request மற்றும் response இரண்டிற்கும் பொருந்தும்.
Header பெயர்கள் case insensitive, ஒவ்வொரு வரியும் carriage return மற்றும் line feed கொண்டு முடிவடையும். இவற்றை நீங்கள் கையால் தட்டச்சு செய்ய மாட்டீர்கள், ஆனால் packet capture-ல் இவற்றைக் காண்பீர்கள்.
உண்மையான pair-ஐக் கண்காணிக்க, உங்களுக்குச் சொந்தமான ஒரு site-ல் இதை இயக்கவும்:
curl -sS -o /dev/null -D - https://example.com/-D - response தலைப்புகளை உங்கள் terminal-ல் எழுதும், -o /dev/null body-ஐ நீக்கிவிடும். curl -I-க்கு பதிலாக இதைப் பயன்படுத்தவும், ஏனெனில் -I ஒரு HEAD request-ஐ அனுப்பும். HEAD மற்றும் GET-ஐ வெவ்வேறாகக் கையாளும் ஒரு application server, எந்த browser-ம் பெறாத தலைப்புகளை உங்களுக்குக் காட்டும். curl -v இரண்டு பக்கங்களையும் அச்சிடும், இதில் request வரிகள் > என்றும், response வரிகள் < என்றும் குறிக்கப்பட்டிருக்கும்.
உங்கள் nginx access log-ல் request line எவ்வாறு இருக்கும்
nginx ஒரு combined log format-ஐ வழங்குகிறது, அதன் வரையறை இதோ:
log_format combined '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';அதன் மூலம் உருவாக்கப்பட்ட ஒரு வரி:
203.0.113.45 - - [06/Aug/2026:09:12:44 +0000] "GET /pricing HTTP/1.1" 200 5310 "https://example.com/" "Mozilla/5.0 (X11; Linux x86_64) Chrome/127.0.0.0 Safari/537.36"203.0.113.45என்பது$remote_addrஆகும், இது TCP (transmission control protocol) இணைப்பைத் திறந்த முகவரி. ஒரு proxy-க்கு பின்னால் இருக்கும்போது, இது பார்வையாளரின் முகவரி அல்ல, proxy-ன் முகவரியாகும்.- முதல்
-ஒரு நிலையான placeholder. இரண்டாவது$remote_userஆகும், இது HTTP basic authentication பயன்பாட்டில் இருக்கும்போது மட்டுமே நிரப்பப்படும். "GET /pricing HTTP/1.1"என்பது$requestஆகும், இது வந்தபடியே நகலெடுக்கப்பட்ட request line ஆகும்.200என்பது உங்கள் server வழங்கிய status ஆகும், பார்வையாளர் கண்ட status அல்ல.5310என்பது$body_bytes_sentஆகும், இது body-ன் அளவு மட்டுமே. Response headers கணக்கிடப்படுவதில்லை, எனவே இந்த எண் உண்மையில் அனுப்பப்பட்ட bytes-ஐ விட எப்போதும் குறைவாகவே இருக்கும்.- மேற்கோள் காட்டப்பட்ட கடைசி இரண்டு புலங்கள்
Refererமற்றும்User-Agentஆகும். இவை இரண்டும் client-லிருந்து வருவதால், அவை எதையும் கொண்டிருக்கலாம்.
$request அப்படியே நகலெடுக்கப்படுவதால், தேவையற்ற தரவுகளும் அப்படியே தோன்றும். உங்கள் plaintext port 80-க்கு TLS (transport layer security) மூலம் பேசும் ஒரு client, 400 வரியை விட்டுச் செல்லும், அதன் request field "\x16\x03\x01\x02\x00\x01" போன்ற escaped bytes-ல் தொடங்கும். \x16 என்பது TLS handshake record type ஆகும், எனவே அந்த bytes ஒரு request line அல்ல, அது ஒரு ClientHello-ன் தொடக்கமாகும். உங்கள் server சரியாகவே செயல்படுகிறது. ஏதோ ஒன்று HTTPS-ஐ ஒரு HTTP port-க்கு அனுப்புகிறது.
உங்கள் log format-ல் $server_protocol-ஐயும் சேர்க்கவும். இது HTTP/1.1, HTTP/2.0 அல்லது HTTP/3.0-ஐ அச்சிடும், மேலும் protocol மாற்றம் உண்மையில் நடைமுறைக்கு வந்துவிட்டதா என்பதை நிரூபிக்க இதுவே வேகமான வழியாகும்.
உங்கள் தளம் திரும்ப அனுப்பும் பொதுவான status codes-ன் விளக்கம்
முதல் இலக்கம் அந்த குறியீட்டின் வகையைக் குறிக்கும்; அதைத்தான் நீங்கள் முதலில் கவனிக்க வேண்டும்.
2xx என்பது செயல் வெற்றி பெற்றதைக் குறிக்கும். சாதாரண வாசிப்பிற்கு 200 OK பயன்படும். ஏதேனும் ஒன்றை உருவாக்கிய பிறகு POST-க்கு பதிலாக 201 Created வரும். எதையும் திருப்பி அனுப்பத் தேவையில்லாத வெற்றிக்கு 204 No Content பயன்படும், இது பொதுவாக DELETE-க்கான பதிலாகும்.
3xx என்பது வேறொரு இடத்தைப் பார்க்கச் சொல்வதைக் குறிக்கும். 301 என்பது நிரந்தரமானது, உலாவிகள் இதைத் தீவிரமாக cache செய்யும். சில நேரங்களில் பயனர் தனது profile-ஐ அழிக்கும் வரை இது நீடிக்கும், எனவே தவறான hostname-ஐக் காட்டும் 301-ஐச் சரிசெய்வது கடினம். நீங்கள் redirect-ஐச் சோதிக்கும்போது 302-ஐப் பயன்படுத்தவும். 304 Not Modified என்பது பிழையல்ல, ஒரு வெற்றியாகும்: client அனுப்பிய If-None-Match-ல் உங்களுக்குத் தெரிந்த ETag (entity tag) இருந்ததால், நீங்கள் body இல்லாமல் headers-ஐ மட்டும் திருப்பி அனுப்பியுள்ளீர்கள். log-ல் நிறைய 304-கள் இருந்தால், caching சரியாக வேலை செய்கிறது என்று அர்த்தம்.
4xx என்பது கோரிக்கையில் பிழை இருப்பதைக் குறிக்கும். 400 Bad Request என்பது தவறான உள்ளீட்டைக் குறிக்கும். 401 Unauthorized என்பது அங்கீகாரம் பெறாததைக் குறிக்கும், இது கட்டாயமாக WWW-Authenticate header-ஐக் கொண்டிருக்க வேண்டும். 403 Forbidden என்பது கோரிக்கை புரிந்துகொள்ளப்பட்டது, ஆனால் நிராகரிக்கப்பட்டது என்று பொருள். 404 Not Found என்பது இல்லாத ஒரு பாதையைக் குறிக்கும். 405 Method Not Allowed என்பது சரியான பாதை, ஆனால் தவறான method என்று பொருள்; static file இருக்கும் இடத்திற்கு POST அனுப்பினால் இதுவே கிடைக்கும். 413 என்பது nginx-ன் client_max_body_size அளவை விட body பெரியதாக இருப்பதைக் குறிக்கும்; இது இயல்பாக 1 megabyte ஆக இருக்கும், பிழை log-ல் client intended to send too large body என்று பதிவாகும்.
ஒரு static file-ல் 403 ஏற்பட்டால், அது பெரும்பாலும் HTTP விதியால் அல்ல, filesystem-ஆல் ஏற்படும். எந்தவொரு config-ஐ மாற்றும் முன்பும் /var/log/nginx/error.log-ஐப் படிக்கவும். open() "/srv/site/index.html" failed (13: Permission denied) என்பது nginx worker user-ஆல் கோப்பை வாசிக்க முடியவில்லை என்று பொருள்; பெரும்பாலும் parent directory-க்கு மற்றவர்களுக்கான execute அனுமதி இல்லாததே இதற்குக் காரணம். directory index of "/srv/site/" is forbidden என்பது, autoindex முடக்கப்பட்டிருக்கும்போது, ஒரு directory-ல் index file இல்லை என்று பொருள்.
5xx என்பது உங்கள் தரப்பில் பிழை இருப்பதைக் குறிக்கும். 500 என்பது உங்கள் application-ல் கையாளப்படாத பிழையைக் குறிக்கும். 502 Bad Gateway என்பது upstream-லிருந்து nginx-ஆல் சரியான பதிலைப் பெற முடியவில்லை என்று பொருள்; பிழை log-ல் அதற்கான காரணம் இருக்கும்: connect() failed (111: Connection refused) while connecting to upstream என்பது proxy_pass முகவரியில் எந்த service-ம் இயங்கவில்லை என்று பொருள். 504 Gateway Timeout என்பது upstream இணைப்பை ஏற்றுக்கொண்டு, proxy_read_timeout-க்குள் (இயல்பாக 60 வினாடிகள்) எந்தப் பதிலும் அளிக்கவில்லை என்று பொருள்; இது log-ல் upstream timed out (110: Connection timed out) while reading response header from upstream என்று பதிவாகும். 503 Service Unavailable என்பது வேண்டுமென்றே இணைப்பை மறுப்பதாகும். nginx-ன் rate limiter 503-ஐத் திருப்பி அனுப்பும் என்பதை கவனத்தில் கொள்க, ஏனெனில் limit_req_status இயல்பாக 503 என்று இருக்கும். உங்கள் log-ல் 429 Too Many Requests-ஐத் தேடி, அதற்குப் பதிலாக 503-ஐக் கண்டால், அதற்குக் காரணம் இதுதான். சரியான குறியீட்டைப் பெற limit_req_status 429;-ஐ அமைக்கவும்.
server-ஐ இயக்கும்போது கவனிக்க வேண்டிய headers
Host என்பது தளத்தைத் தேர்வு செய்கிறது. ஒரு IP address-ல் நூற்றுக்கணக்கான hostnames-ஐ வழங்க முடியும். எந்த server block பதிலளிக்க வேண்டும் என்பதைத் தீர்மானிக்க nginx Host-ஐ server_name உடன் ஒப்பிடுகிறது. எதுவும் பொருந்தவில்லை எனில், nginx default server-ஐப் பயன்படுத்தும். இது அந்த முகவரி மற்றும் port-ல் கேட்கும் முதல் block ஆகும்; வேறொன்று default_server எனக் குறிப்பிடப்பட்டிருந்தால் தவிர. புதிய virtual host-ல் தவறான தளம் கிடைக்கிறது என்றால், பெரும்பாலும் பெயர் பொருந்தாததால் கோரிக்கை default block-க்குச் சென்றதே காரணமாக இருக்கும். DNS-ஐ மாற்றாமல் இதைச் சோதிக்கவும்:
curl -sS -o /dev/null -D - -H 'Host: app.example.com' http://127.0.0.1/User-Agent என்பது client-ஆல் எழுதப்படும் ஒரு சுயவிவரம்; இது ஒரு தன்னிச்சையான உரை. logs-ஐப் படிக்கும்போது இதை ஒரு குறிப்பாகப் பயன்படுத்தவும். இதை ஒரு கட்டுப்பாட்டு கருவியாகப் பயன்படுத்த வேண்டாம். ஏனெனில், பொய் சொல்ல விரும்பும் client எளிதாக அதைச் செய்துவிடும். எனவே, User-Agent மூலம் ஒரு scraper-ஐத் தடுப்பது கண்ணியமானவற்றை மட்டுமே நீக்கும்.
Content-Type என்பது bytes எவ்வாறு புரிந்துகொள்ளப்பட வேண்டும் என்பதைத் தீர்மானிக்கிறது: API கோரிக்கைக்கு application/json, ஒரு பக்கத்திற்கு text/html; charset=utf-8. nginx கோப்பு நீட்டிப்புகளை (file extensions) /etc/nginx/mime.types மூலம் வகைகளுடன் இணைக்கிறது. தொகுக்கப்பட்ட nginx.conf, default_type application/octet-stream;-ஐ அமைக்கிறது. எனவே, nginx-க்குத் தெரியாத நீட்டிப்பு கொண்ட கோப்பு, திரையில் காட்டப்படுவதற்குப் பதிலாக download செய்யக் கேட்கப்படும். இதன் அறிகுறி, browser console-ல் Refused to apply style from ... because its MIME type ('text/plain') is not a supported stylesheet MIME type பிழை காட்டப்படும்போது, பக்கம் எந்த வடிவமைப்பும் (styling) இன்றித் தோன்றுவதாகும். MIME என்பது Multipurpose Internet Mail Extensions என்பதைக் குறிக்கும்; இந்த வகை strings-கள் இதிலிருந்தே வருகின்றன.
Cache-Control என்பது உங்கள் server-க்கும் வாசகருக்கும் இடையில் உள்ள ஒவ்வொரு cache-ஐயும் கட்டுப்படுத்தும் முறையாகும். கோப்பின் பெயரில் content hash இருந்தால், public, max-age=31536000, immutable பொருத்தமானது; ஏனெனில் உள்ளடக்கம் மாறும்போது பெயரும் மாறிவிடும். பயனர் சார்ந்த எதற்கும் no-store பயன்படுத்த வேண்டும்; ஏனெனில், login செய்யப்பட்ட பக்கத்தைச் சேமிக்கும் ஒரு shared cache, அதே URL-ஐக் கேட்கும் அடுத்த நபருக்கு அந்தப் பக்கத்தைக் காட்டிவிடும். private என்பது இடைப்பட்ட அமைப்பாகும்: browser இதைச் சேமிக்கலாம், ஆனால் shared cache சேமிக்கக்கூடாது.
X-Forwarded-For என்பது proxy பார்வையாளரை மறைப்பதால் தேவைப்படுகிறது. ஒரு கோரிக்கை reverse proxy வழியாகச் செல்லும்போது, $remote_addr என்பது proxy-ன் முகவரியாக இருக்கும். இதனால் உங்கள் logs, geolocation மற்றும் rate limiting ஆகியவை ஒரே client-ஐ மட்டுமே பார்க்கும். எனவே, proxy அசல் முகவரியை அனுப்ப வேண்டும்:
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;பெறும் server, அந்த முகவரியை நம்புமாறும், யாரை நம்ப வேண்டும் என்பதையும் துல்லியமாகத் தெரிந்து வைத்திருக்க வேண்டும்:
set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;நீங்கள் கட்டுப்படுத்தும் IP ranges-ஐ மட்டும் பட்டியலிடவும். X-Forwarded-For என்பது எந்த client-உம் அனுப்பக்கூடிய சாதாரண உரை. எனவே, set_real_ip_from 0.0.0.0/0;-ஐப் பயன்படுத்தினால், ஒரு பார்வையாளர் நீங்கள் log செய்யும் முகவரியையும், உங்கள் rate limiter கணக்கிடும் முகவரியையும் மாற்ற முடியும்.
X-Forwarded-Proto ஒரு பொதுவான மற்றும் குறிப்பிட்ட தோல்வியைத் தடுக்கிறது. உங்கள் proxy TLS-ஐ முடித்துவிட்டு, plain HTTP வழியாக application-க்குக் கோரிக்கையை அனுப்புகிறது. application ஒரு plain கோரிக்கையைப் பார்த்து, பார்வையாளர் HTTPS-ல் இருக்க வேண்டும் என முடிவு செய்து, 301 https://example.com/ எனப் பதிலளிக்கிறது. browser அதைப் பின்தொடர்கிறது, proxy மீண்டும் TLS-ஐ முடித்துவிட்டு plain HTTP-ஐ அனுப்புகிறது. browser ERR_TOO_MANY_REDIRECTS பிழையைக் காட்டும் வரை இந்தச் சுழற்சி தொடரும். X-Forwarded-Proto: https-ஐ அனுப்புவதன் மூலம், பார்வையாளர் ஏற்கனவே HTTPS-ல் இருக்கிறார் என்பதை application-க்குத் தெரிவிக்கலாம்; இதனால் அது redirect செய்வதை நிறுத்திவிடும்.
HTTP/1.1, HTTP/2 மற்றும் HTTP/3: உங்களுக்கு என்ன மாற்றங்கள்
HTTP/1.1 என்பது உரை (text) அடிப்படையிலானது, இது ஒரு இணைப்பில் (connection) ஒரு நேரத்தில் ஒரு கோரிக்கையை மட்டுமே கையாளும். Connection: keep-alive அடுத்தடுத்த கோரிக்கைகளை அதே TCP இணைப்பிலேயே பயன்படுத்த அனுமதிக்கிறது, இது இணைப்பு அமைப்பதற்கான செலவைக் குறைக்கிறது. இருப்பினும், கோரப்பட்ட அதே வரிசையிலேயே பதில்களும் வருகின்றன. ஒரு மெதுவான பதில், அதற்குப் பின்னால் வரிசையில் உள்ள அனைத்தையும் தடுத்து நிறுத்தும். இதுவே head-of-line blocking எனப்படும். உலாவிகள் (browsers) ஒரே நேரத்தில் ஒரே hostname-க்கு பல இணைப்புகளைத் திறந்து இதைத் தவிர்க்கின்றன.
HTTP/2 அதே முறைகளையும் (methods) அதே status codes-களையும் தக்கவைத்துக்கொண்டு, தரவு அமைப்பை binary-க்கு மாற்றுகிறது. பல கோரிக்கைகள் ஒரே இணைப்பைச் சுதந்திரமான streams-களாகப் பகிர்ந்து கொள்கின்றன. மீண்டும் மீண்டும் வரும் header உரை சுருக்கப்படுகிறது (compressed); நவீன கோரிக்கைகளில் இவை அதிகமாக இருப்பதால் இது முக்கியமானது. இந்த இணைப்பு இன்னும் TCP-ஆகவே இருப்பதால், ஒரு packet தொலைந்தால், அது மீண்டும் வரும் வரை அந்த இணைப்பில் உள்ள அனைத்து streams-களும் முடங்கும். Head-of-line blocking மறையவில்லை; அது HTTP-லிருந்து transport அடுக்குக்கு நகர்ந்துள்ளது. HTTP/2-ல் இருந்த Server push, நடைமுறையில் பயன்பாட்டில் இல்லை, ஏனெனில் 2022-ல் Chrome இதற்கான ஆதரவை நீக்கிவிட்டது.
HTTP/3 மீண்டும் அதே semantics-ஐத் தக்கவைத்துக்கொண்டு, TCP-க்கு பதிலாக UDP (user datagram protocol)-ல் கட்டமைக்கப்பட்ட QUIC-ஐப் பயன்படுத்துகிறது. QUIC streams-கள் முழுமையாகச் சுதந்திரமானவை, எனவே ஒரு packet தொலைந்தால், அது சார்ந்த stream மட்டுமே முடங்கும். TLS 1.3, QUIC handshake-லேயே கட்டமைக்கப்பட்டுள்ளது, எனவே புதிய இணைப்புக்குக் குறைவான round trips போதுமானது. இதனால் இரண்டு நடைமுறை விளைவுகள் ஏற்படுகின்றன: பாதையில் உள்ள அனைத்து firewall-களிலும் UDP port 443 திறந்திருக்க வேண்டும், மேலும் UDP-ஐக் கட்டுப்படுத்தும் அல்லது தடுக்கும் எந்தவொரு network-ம் வாடிக்கையாளர்களை மீண்டும் HTTP/2-க்கே தள்ளும்.
உங்களுக்கு என்ன மாற்றங்கள், சுருக்கமாக. உலாவிகள் ஒருபோதும் HTTP/3-ல் தொடங்காது. அவை HTTP/2 அல்லது HTTP/1.1 வழியாக இணையும், பதிலில் உள்ள Alt-Svc: h3=":443"; ma=86400 header-ஐப் பார்த்துவிட்டு, அந்த host-க்கான அடுத்தடுத்த இணைப்புகளுக்கு HTTP/3-ஐப் பயன்படுத்தும். எனவே, இந்த header ஒரு விருப்பத்தேர்வு அல்ல; இதுவே கண்டறியும் பொறிமுறை (discovery mechanism). nginx-ல், பதிப்பு 1.25.1-ல் HTTP/2 தனி directive-ஆக மாறியது (server block-க்குள் http2 on;, இது பழைய listen ... http2 parameter-க்கு மாற்றாக வந்தது). QUIC, mainline 1.25.0-ல் அறிமுகமானது, அங்கு ஒரு HTTP/3 தளத்திற்கு சாதாரண listen 443 ssl; உடன் சேர்த்து listen 443 quic reuseport; தேவைப்படுகிறது.
Proxy-களின் முதிர்ச்சி இதில் மாறுபடும், நீங்கள் பயன்படுத்தும் பதிப்பைச் சரிபார்ப்பது அவசியம். ஆகஸ்ட் 2026 நிலவரப்படி, Caddy எந்தக் கட்டமைப்பும் இன்றி இயல்பாகவே HTTP/3-ஐ வழங்குகிறது. nginx-க்கு வெளிப்படையான quic listener மற்றும் மேலே விவரிக்கப்பட்ட Alt-Svc header தேவை. Traefik, http3 விருப்பத்தின் மூலம் ஒவ்வொரு entry point-க்கும் இதைச் செயல்படுத்துகிறது. நீங்கள் Traefik in front of several Docker apps-ல் TLS-ஐ முடித்தால், உங்கள் பார்வையாளர்கள் பெறும் protocol பதிப்பு அங்கேயே தீர்மானிக்கப்படுகிறது. Proxy-யிலிருந்து உங்கள் container-க்குச் செல்லும் இணைப்பு, உலாவி எதைப் பேச்சுவார்த்தை நடத்தினாலும், பொதுவாக plain HTTP/1.1-ஆகவே இருக்கும்.
ஊகிப்பதை விடச் சரிபார்ப்பது சிறந்தது. curl -V அதன் அம்சங்களில் HTTP3-ஐக் கொண்டிருந்தால் மட்டுமே curl --http3 -sS -o /dev/null -D - https://example.com/ வேலை செய்யும், பெரும்பாலான விநியோகக் கட்டமைப்புகளில் (distribution builds) இது சேர்க்கப்படுவதில்லை. நம்பகமான சரிபார்ப்பு உங்கள் log-ல் உள்ளது: format-ல் $server_protocol-ஐச் சேர்த்து, உண்மையான உலாவிகள் எதைப் பேச்சுவார்த்தை நடத்துகின்றன என்பதைப் படிக்கவும். இவை அனைத்திற்கும் முன்னதாக, UDP 443 திறந்திருப்பதை உறுதிப்படுத்தவும். ஏனெனில் TCP 443-ஐ மட்டும் அனுமதிக்கும் firewall, தளம் HTTP/2-ல் வேலை செய்தாலும் HTTP/3-ஐ அமைதியாகத் தோல்வியடையச் செய்யும். which ports are open and listening on your Linux server என்பதை அறிந்துகொள்வதே முதலில் செய்ய வேண்டிய காரியம்.
HTTPS: HTTP என்பது protocol, TLS என்பது அதன் உறை (wrapper)
HTTPS என்பது தனிப்பட்ட protocol அல்ல. இது TLS session-க்குள் கொண்டு செல்லப்படும் அதே HTTP requests மற்றும் status codes-களின் தொகுப்பாகும். Port 80-ல் இவை மறைமுகமின்றி (in the clear) அனுப்பப்படுகின்றன, port 443-ல் இவை குறியாக்கப்பட்டு (encrypted) அனுப்பப்படுகின்றன. முதலில் TLS handshake நிறைவடையும், அதன் பிறகே HTTP request குறியாக்கம் செய்யப்பட்ட channel வழியாகச் செல்லும். இந்த வரிசைமுறை காரணமாகவே, certificate தொடர்பான சிக்கல்களுக்கு எந்தவொரு status code-ம் வழங்கப்படுவதில்லை: HTTP byte அனுப்பப்படுவதற்கு முன்பே தோல்வி நிகழ்ந்துவிடுவதால், பதிலளிக்க எந்த எண்ணும் இருப்பதில்லை.
பல தளங்களை (sites) இயக்கும் server-ல் ஒரு வரிசைமுறை முக்கியமானது. TLS handshake-ல் உள்ள SNI (server name indication) என்ற field மூலம் certificate தேர்ந்தெடுக்கப்படுகிறது. இது எந்தவொரு HTTP header-ம் உருவாவதற்கு முன்பே, hostname-ஐ மறைமுகமின்றி (in the clear) கொண்டு செல்கிறது. எனவே, server முதலில் SNI மூலம் ஒரு certificate-ஐத் தேர்ந்தெடுக்கிறது, அதன் பிறகு இரண்டாவது படியாக Host header-லிருந்து virtual host-ஐத் தேர்ந்தெடுக்கிறது. இவை இரண்டும் தனித்தனி தேடல்கள், இவை பொதுவாக ஒத்துப்போகும். இவை ஒத்துப்போகாதபோது, browser NET::ERR_CERT_COMMON_NAME_INVALID போன்ற name mismatch பிழையைக் காட்டும் மற்றும் எந்த request-ஐயும் அனுப்பாது; ஏனெனில், உங்கள் default server-ன் certificate, அது உள்ளடக்காத ஒரு பெயருக்காக வழங்கப்பட்டிருக்கும்.
பொதுத் தளத்திற்கு (public site), உண்மையான certificate-ஐப் பெற்று, அதைத் தானாகவே புதுப்பிக்கும்படி அமைக்கவும். Certbot with Let's Encrypt on nginx, certificate paths-ஐ உங்கள் server block-ல் எழுதி, உங்களுக்காக renewal timer-ஐ நிறுவும். பொது அதிகார அமைப்பால் சரிபார்க்க முடியாத hostname-களுக்கு, அதாவது internal name அல்லது உங்கள் சொந்த network-ல் உள்ள bare IP address-க்கு, a self-signed certificate on Ubuntu ஒரு சரியான தேர்வாகும்; ஆனால், ஒவ்வொரு client-ம் அதை நம்பும்படி செய்ய வேண்டும் என்பதை நீங்கள் ஏற்க வேண்டும்.
TLS சரியாகச் செயல்பட்டவுடன், port 80-ல் வரும் அனைத்தையும் port 443-க்கு அனுப்பவும்:
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}நீங்கள் உறுதியாக இருக்கும்போது மட்டுமே Strict-Transport-Security-ஐச் சேர்க்கவும். add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always; header, அந்த hostname-க்கு இரண்டு ஆண்டுகளுக்கு plain HTTP-ஐ ஏற்க வேண்டாம் என்று browser-களுக்குக் கட்டளையிடுகிறது. browser-கள் அதைத் தங்கள் cache-லிருந்து பின்பற்றும், எனவே அந்த header-ஐப் பிறகு நீக்கினாலும் அது மாறாது. முதலில் சில மணிநேரங்களுக்கு max-age-ஐ அமைத்து, அனைத்து subdomain-களும் HTTPS-ல் இருப்பதை உறுதிசெய்த பிறகு, அதை அதிகரிக்கவும்.
FAQ
HTTP மற்றும் HTTPS-க்கு இடையே உள்ள வேறுபாடு என்ன?
HTTPS என்பது TLS (transport layer security) அமர்வுக்குள் அனுப்பப்படும் HTTP ஆகும். இதில் பயன்படுத்தப்படும் முறைகளும் (methods) status code-களும் ஒரே மாதிரியானவை. இதில் மாறுவது என்னவென்றால், client-க்கும் TLS-ஐ முடிக்கும் (terminate) இடத்திற்கும் இடையே தரவுகள் குறியாக்கப்படுகின்றன (encrypted). மேலும், இயல்பான port 80-லிருந்து 443-க்கு மாறுகிறது. TLS handshake முடிவதற்கு முன்பே HTTP தரவுகள் அனுப்பப்படுவதில்லை என்பதால், certificate தோல்வி ஒருபோதும் status code-ஐ உருவாக்குவதில்லை. இதனால்தான் browser-ல் certificate எச்சரிக்கை வரும்போது 403 போன்ற எண்ணிற்குப் பதிலாக NET::ERR_CERT_COMMON_NAME_INVALID போன்ற பிழைப் பெயர் காட்டப்படுகிறது.
எனது தளம் ஏன் 502 Bad Gateway பிழையைக் காட்டுகிறது?
Nginx-லிருந்து வரும் 502 என்பது, அது proxy செய்யும் upstream-லிருந்து சரியான பதிலைப் பெற முடியவில்லை என்பதைக் குறிக்கிறது. எனவே, visitor-ன் கோரிக்கை சரியாக உள்ளது, ஆனால் nginx-க்கு பின்னால் உள்ள ஏதோ ஒன்று சரியாகச் செயல்படவில்லை. /var/log/nginx/error.log-ஐப் படிக்கவும். connect() failed (111: Connection refused) while connecting to upstream என்பது proxy_pass-ல் உள்ள முகவரி மற்றும் port-ல் எந்தச் சேவையும் இயங்கவில்லை என்பதைக் குறிக்கிறது. எனவே, application இயங்குகிறதா என்பதையும், நீங்கள் எதிர்பார்த்த இடத்தில் அது bound ஆகியுள்ளதா என்பதையும் சரிபார்க்கவும். no live upstreams while connecting to upstream என்பது, தொடர்ச்சியான தோல்விகளுக்குப் பிறகு upstream block-ல் உள்ள அனைத்து server-களும் முடக்கப்பட்டுள்ளன என்பதைக் குறிக்கிறது. 504 Gateway Timeout-உடன் ஒப்பிட்டுப் பார்க்கவும்; இது upstream இணைப்பை ஏற்றுக்கொண்டு, proxy_read_timeout-க்குள் பதிலளிக்கத் தவறியதைக் குறிக்கிறது.
எனது access log-ல் அனைத்து visitor-களுக்கும் ஒரே IP முகவரி ஏன் காட்டப்படுகிறது?
ஏனெனில், $remote_addr என்பது TCP இணைப்பைத் திறந்த முகவரியைப் பதிவு செய்கிறது. ஒரு reverse proxy அல்லது content delivery network-க்கு பின்னால் இருக்கும்போது, அந்த முகவரி proxy-யாகவே இருக்கும். visitor-ன் முகவரி X-Forwarded-For header-ல் மட்டுமே கிடைக்கும். proxy-யில் proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;-ஐ அமைக்கவும். பின்னர், பெறும் nginx-ல் set_real_ip_from-ஐ proxy-யின் முகவரி வரம்பிற்கு அமைத்து, real_ip_header X-Forwarded-For;-ஐச் சேர்க்கவும். நீங்கள் கட்டுப்படுத்தும் வரம்புகளை மட்டும் பட்டியலிடவும். ஏனெனில், அந்த header-ஐ எந்தவொரு client-ம் அனுப்ப முடியும். எனவே, இணையம் முழுவதையும் நம்புவது, visitor-கள் தாங்கள் விரும்பும் முகவரியைப் பதிவு செய்யவும், rate limit செய்யவும் வழிவகுக்கும்.
நான் HTTP/2 அல்லது HTTP/3-ஐ இயக்க வேண்டுமா?
HTTP/2-ஐ இயக்குவது பயனுள்ளது. ஏனெனில், ஏற்கனவே TLS உள்ள தளத்தில் இது ஒரே ஒரு directive மட்டுமே. இது பல சிறிய கோப்புகளைக் கொண்ட பக்கங்களை மெதுவாக்கும் connection-க்கு ஒரு கோரிக்கை என்ற வரம்பை நீக்குகிறது. HTTP/3-ல் கிடைக்கும் லாபம் குறைவு மற்றும் நிச்சயமற்றது. இதற்கு UDP port 443-ஐத் திறக்க வேண்டும் மற்றும் QUIC ஆதரவுடன் கூடிய proxy-ஐ உருவாக்க வேண்டும். browsers முந்தைய பதிலில் Alt-Svc header-ஐப் பார்த்த பிறகுதான் HTTP/3-க்கு மாறும் என்பதை நினைவில் கொள்க. அந்த header இல்லையென்றால், உங்கள் listen வரி என்ன சொன்னாலும் எதுவும் மாறாது. $server_protocol-ஐ உங்கள் log format-ல் சேர்த்து, நேரத்தைச் செலவிடுவதற்கு முன்பு visitor-கள் உண்மையில் எதை negotiate செய்கிறார்கள் என்பதை அளவிடவும்.
கோப்பு இருந்தும் 403 Forbidden என்று ஏன் வருகிறது?
ஒரு static தளத்தில், 403 என்பது பொதுவாக HTTP விதியைக் காட்டிலும் filesystem அனுமதி தொடர்பான சிக்கலாகும். /var/log/nginx/error.log-ல் உள்ள open() ... failed (13: Permission denied) என்பது, nginx worker user-ஆல் கோப்பை வாசிக்க முடியவில்லை என்பதைக் குறிக்கிறது. பெரும்பாலும், கோப்பின் mode தவறாக இருப்பதைக் காட்டிலும், parent directory-க்கு மற்றவர்களுக்கான execute அனுமதி இல்லாததே இதற்குக் காரணமாக இருக்கும். directory index of ... is forbidden என்பது, கோரிக்கை ஒரு directory-க்குச் சென்று, அங்கு index கோப்பு இல்லை என்பதையும், autoindex முடக்கப்பட்டிருப்பதையும் குறிக்கிறது. பொருந்தக்கூடிய location block-ல் உள்ள ஒரு தெளிவான deny விதியும் 403-ஐத் தரும். எனவே, error log-ல் எதுவும் இல்லை என்றால் அந்த block-ஐப் படிக்கவும்.