UDP வழியாக HTTP - QUIC நெறிமுறையை நன்றாகப் பயன்படுத்துகிறது

QUIC (விரைவு UDP இணைய இணைப்புகள்) என்பது UDPயின் மேல் உள்ள ஒரு நெறிமுறையாகும், இது TCP, TLS மற்றும் HTTP/2 இன் அனைத்து அம்சங்களையும் ஆதரிக்கிறது மற்றும் அவற்றின் பெரும்பாலான சிக்கல்களைத் தீர்க்கிறது. இது பெரும்பாலும் ஒரு புதிய அல்லது "பரிசோதனை" நெறிமுறை என்று அழைக்கப்படுகிறது, ஆனால் இது நீண்ட காலமாக சோதனைக் கட்டத்தை விட அதிகமாக உள்ளது: வளர்ச்சி 7 ஆண்டுகளுக்கும் மேலாக நடந்து வருகிறது. இந்த நேரத்தில், நெறிமுறை ஒரு நிலையானதாக மாறவில்லை, ஆனால் இன்னும் பரவலாக மாறியது. எடுத்துக்காட்டாக, ட்ராஃபிக்கை விரைவுபடுத்தவும் மொபைல் நெட்வொர்க்குகளில் ஏற்படும் தாமதங்களைக் குறைக்கவும் கூகுள் மற்றும் ஃபேஸ்புக் போன்ற ஜாம்பவான்களால் QUIC ஐப் பயன்படுத்துகிறது, மேலும் IETF ஆனது HTTP/3 தரநிலையின் அடிப்படையை (HTTP/2 பயன்படுத்தினாலும்) அதன் ஃபோர்க் நெறிமுறையை அறிவித்தது. 44.8% மட்டுமே தளங்கள்).

கருத்து

QUIC பாரம்பரிய TCP க்கு மாற்றாக உருவாக்கப்பட்டது, இது முதலில் குறைந்த இழப்பு கம்பி நெட்வொர்க்குகளுக்காக வடிவமைக்கப்பட்டது. TCP பாக்கெட்டுகளை வரிசையாக வழங்குகிறது, எனவே ஒரு பாக்கெட் தொலைந்துவிட்டால், முழு வரிசையும் நிறுத்தப்படும் (தலை-ஆஃப்-லைன் தடுப்பு), இது இணைப்பின் தரம் மற்றும் நிலைத்தன்மையை எதிர்மறையாக பாதிக்கிறது. பாரிய இழப்புகளைத் தவிர்க்க, செல்லுலார் நெட்வொர்க்குகள் பெரிய இடையகங்களைப் பயன்படுத்துகின்றன, இது பணிநீக்கம் மற்றும் நெறிமுறையின் தவறான எதிர்மறையான பதிலுக்கு வழிவகுக்கிறது (தாங்கல்) கூடுதலாக, TCP ஒரு இணைப்பை நிறுவுவதற்கு அதிக நேரம் செலவிடுகிறது: SYN/ACK மற்றும் TLS கோரிக்கைகள் தனித்தனியாக செயலாக்கப்படும், QUIC செய்வது போல, ஒன்றிற்கு பதிலாக மூன்று சுற்றுப்பயணங்கள் தேவைப்படுகின்றன.

QUIC ஆனது TCP மாற்றீடு மற்றும் TLS 1.3 இன் செயலாக்கத்தை இணைப்பதால், எல்லா இணைப்புகளும் எப்போதும் குறியாக்கம் செய்யப்படுகின்றன, மேலும் அத்தகைய போக்குவரத்தை மறைகுறியாக்கம் செய்வது HTTPS வழியாக செல்வதை விட எளிதானது அல்ல. கூடுதலாக, QUIC பயன்பாட்டு மட்டத்தில் செயல்படுத்தப்படுகிறது, ஏனெனில் TCP ஸ்டேக்கை முழுமையாக மாற்ற வேண்டும் நித்தியம்.

HTTP/2 இல் மல்டிபிளெக்சிங்கிற்கான ஆதரவு இருந்தபோதிலும், பாக்கெட்டுகளை வரிசையாக வழங்க வேண்டியதன் காரணமாக ஹெட்-ஆஃப்-லைன் தடுப்பதில் சிக்கல் இருந்தது. QUIC UDP க்கு மேல் செயல்படுத்தப்படுகிறது, எனவே இதற்கு கொள்கையளவில் எந்தத் தடையும் இல்லை, மேலும் பாக்கெட்டுகள் எப்போதும் தொலைந்து போவதைத் தடுக்க, அவை எண்ணிடப்பட்டு, "அண்டை நாடுகளின்" பகுதிகளைக் கொண்டிருக்கலாம் மற்றும் பணிநீக்கத்தை வழங்குகிறது. கூடுதலாக, QUIC ஆனது ஒரே இணைப்பில் உள்ள பல்வேறு வகையான கோரிக்கைகளுக்காக ஒற்றைக்கல் வரிசையை பல நூல்களாக பிரிக்கிறது. எனவே, ஒரு பாக்கெட் தொலைந்துவிட்டால், ஒரு வரிசையில் மட்டுமே சிக்கல்கள் ஏற்படலாம் (எடுத்துக்காட்டாக, ஒரு குறிப்பிட்ட கோப்பை மாற்றுவதற்கு):

பயன்படுத்த

ஆரம்பத்தில், QUIC ஆனது கூகுளுக்குள் உருவாக்கப்பட்டது மற்றும் பெரும்பாலும் நிறுவனத்திற்குள் பயன்படுத்துவதற்காக வடிவமைக்கப்பட்டது. 2013 ஆம் ஆண்டில், தரநிலைப்படுத்தலுக்காக இது IETF க்கு மாற்றப்பட்டது (இது இன்னும் தொடர்கிறது), இப்போது எல்லோரும் அவர்கள் காணாமல் போனதை முன்மொழிவதன் மூலம் நெறிமுறையின் வளர்ச்சியில் பங்கேற்கலாம். IETF பணிக்குழு வருடாந்திர கூட்டங்களை ஏற்பாடு செய்கிறது, இதன் போது ஒரு புதிய தரநிலை அங்கீகரிக்கப்பட்டு புதுமைகள் விவாதிக்கப்படுகின்றன. QUIC இன் இந்த செயல்படுத்தல் முக்கிய ஒன்றாகக் கருதப்படுகிறது மற்றும் அதன் அடிப்படையில் HTTP/3 தரநிலை சான்றளிக்கப்பட்டது.

இதுவரை, HTTP/3 முக்கிய நெறிமுறையாகச் சேர்ப்பது பற்றி எந்தப் பேச்சும் இல்லை, ஏனெனில் இது இன்னும் முடிக்கப்படவில்லை மற்றும் கிட்டத்தட்ட ஆதரிக்கப்படவில்லை:

ஆனால் பயன்பாட்டிற்கும் சேவையகத்திற்கும் இடையேயான போக்குவரமாக QUIC செயல்படுத்தப்படலாம், இது Uber இல் வெற்றிகரமாக செய்யப்பட்டது:

QUIC இன் அறிமுகம் குறித்து Uber இன் கருத்து

QUIC ஐ வெற்றிகரமாக உட்பொதிக்கவும், மோசமான இணைப்பு சூழல்களில் பயன்பாட்டின் செயல்திறனை மேம்படுத்தவும், பழைய அடுக்கை (HTTP/2 over TLS/TCP) QUIC நெறிமுறையுடன் மாற்றியுள்ளோம். பிணைய நூலகத்தைப் பயன்படுத்தினோம் குரோனெட் из குரோமியம் திட்டங்கள், இது நெறிமுறையின் அசல், Google பதிப்பைக் கொண்டுள்ளது - gQUIC. சமீபத்திய IETF விவரக்குறிப்புகளைப் பின்பற்றுவதற்காக இந்தச் செயலாக்கமும் தொடர்ந்து மேம்படுத்தப்பட்டு வருகிறது.

QUICக்கான ஆதரவைச் சேர்க்க, முதலில் எங்கள் Android பயன்பாடுகளில் Cronet ஐ ஒருங்கிணைத்தோம். இடப்பெயர்வு செலவுகளை முடிந்தவரை குறைக்கும் வகையில் ஒருங்கிணைப்பு மேற்கொள்ளப்பட்டது. நூலகத்தைப் பயன்படுத்திய பழைய நெட்வொர்க்கிங் அடுக்கை முழுமையாக மாற்றுவதற்குப் பதிலாக OkHttp, OkHttp API கட்டமைப்பின் கீழ் க்ரோனெட்டை ஒருங்கிணைத்துள்ளோம். இந்த வழியில் ஒருங்கிணைப்பை செய்வதன் மூலம், எங்கள் நெட்வொர்க் அழைப்புகளில் மாற்றங்களைத் தவிர்த்துவிட்டோம் (அவை பயன்படுத்தப்படுகின்றன தாங்கவல்ல) API அளவில்.

Android சாதனங்களுக்கான அணுகுமுறையைப் போலவே, IOS இல் Uber பயன்பாடுகளில் Cronet ஐ செயல்படுத்தினோம், நெட்வொர்க்கில் இருந்து HTTP டிராஃபிக்கை இடைமறித்தோம் ஏபிஐபயன்படுத்தி NSURLProtocol. iOS அறக்கட்டளை வழங்கிய இந்த சுருக்கமானது, நெறிமுறை சார்ந்த URL தரவைக் கையாளுகிறது மற்றும் குறிப்பிடத்தக்க இடம்பெயர்வு செலவுகள் இல்லாமல் எங்கள் iOS பயன்பாடுகளில் Cronet ஐ ஒருங்கிணைக்க முடியும் என்பதை உறுதி செய்கிறது.

இருந்து எடுக்கப்பட்டது இந்த மொழிபெயர்ப்பு Uber கட்டுரைகள்

பின்தளத்தில் அவர்கள் கூகுள் கிளவுட் எல்பி வழியாக QUIC இணைப்புகளைப் பிடித்தனர் நெறிமுறையை ஆதரிக்கிறது 2018 நடுப்பகுதியில் இருந்து.

கூகிள் உருவாக்கிய நெறிமுறையுடன் கூகிள் கிளவுட் சிறப்பாகச் செயல்படுவதில் ஆச்சரியமில்லை, ஆனால் மாற்று வழிகள் என்ன?

nginx

நீண்ட காலத்திற்கு முன்பு CloudFlare கடக்க முயன்றேன் nginx (இது முன்னிருப்பாக HTTP/3 ஐ ஆதரிக்காது) அதன் Quiche கருவியுடன். செயல்படுத்தல் ஒரு ஒற்றை .patch கோப்பாக கிடைக்கிறது, இது ஒரு நிறுவல் பயிற்சியுடன் வருகிறது:

curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patch

தேவைப்பட்டால் உங்கள் தொகுதிகளை இங்கே இணைக்கலாம்

./configure                          	
   	--prefix=$PWD                       	
   	--with-http_ssl_module              	
   	--with-http_v2_module               	
   	--with-http_v3_module               	
   	--with-openssl=../quiche/deps/boringssl 
   	--with-quiche=../quiche
 make

HTTP/3 ஆதரவை இயக்குவது மட்டுமே எஞ்சியுள்ளது

events {
    worker_connections  1024;
}

http {
    server {
        # Enable QUIC and HTTP/3.
        listen 443 quic reuseport;

        # Enable HTTP/2 (optional).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Enable all TLS versions (TLSv1.3 is required for QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Request buffering in not currently supported for HTTP/3.
        proxy_request_buffering off;

        # Add Alt-Svc header to negotiate HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

வழக்கமான உலாவிகளில் HTTP/3 வழியாக இணைக்க இன்னும் சாத்தியமில்லை, ஆனால் நீங்கள் பயன்படுத்தலாம் குரோம் கேனரி மற்றும் கொடியுடன் அதை இயக்கவும் --enable-quic, உங்கள் சேவையகத்திற்குச் செல்லவும் அல்லது, எடுத்துக்காட்டாக, quic.rocks தளத்திற்குச் சென்று, டெவலப்பர் கருவிகளில் உள்ள இணைப்பு வகையைப் பார்க்கவும்:

HTTP/3க்கு பதிலாக எழுதப்பட்டுள்ளது http2+quic/99, ஆனால் இது அடிப்படையில் அதே விஷயம்.

பிற தொழில்நுட்பங்கள்

• QUIC ஆதரிக்கிறது LiteSpeed (இது பெரும் ஆரவாரத்துடன் HTTP/3 வழியாக Facebook உடன் இணைக்கப்பட்டது) மற்றும் முற்போக்கானது காடியா. அப்பாச்சியால் இன்னும் முடியவில்லை, ஆனால் வேலை நடந்து கொண்டிருக்கிறது முழு ஊஞ்சல்.
• ஜனவரி 21 புதுப்பிக்கப்பட்டது WebRTC க்கான வரைவு தரநிலை
• மறுநாள் மைக்ரோசாப்ட் திறக்கப்பட்டது msquic செயல்படுத்தல் குறியீடு, இதில் IETF தரநிலையிலிருந்து அனைத்து செயல்பாடுகளும் இன்னும் கிடைக்கவில்லை, ஆனால் இது ஏற்கனவே ஒரு பெரிய திருப்புமுனையாகும்.

முடிவுக்கு

QUIC இல் உள்ள ஆர்வம் நிலையற்றது, ஆனால் வளர்ந்து வருகிறது, மேலும் அதை தரப்படுத்துவதற்கான பணிகள் நடைபெற்று வருகின்றன. நெறிமுறையின் புதிய செயலாக்கங்கள் கிட்டத்தட்ட ஒவ்வொரு மாதமும் தோன்றும், மேலும் ஒவ்வொரு ஆண்டும் அதிகமான டெவலப்பர்கள் QUIC தான் எதிர்காலம் என்று நம்புகிறார்கள். TCP அடுக்கின் எதிர்கால பதிப்புகளில் நெறிமுறையைச் சேர்ப்பது கூட சாத்தியமாகும், அதாவது விரைவில் அல்லது பின்னர் முழு இணையமும் மிகவும் நிலையான மற்றும் வேகமான இணைப்புகளுக்கு நகரும்.

ஏற்கனவே இப்போது நீங்கள் உங்கள் உள்கட்டமைப்பிற்கான QUIC தொடர்புகளை உள்ளமைக்கலாம் அல்லது உலாவிகளுக்கு வழங்கலாம் - அவர்கள் அனைவரும் நெறிமுறைக்கு ஆதரவைச் சேர்க்க திட்டமிட்டுள்ளனர், மேலும் கேனியூஸுடன் சோகமான புள்ளிவிவரங்கள் மிகவும் மகிழ்ச்சியாக மாறும்.

ஆதாரம்: www.habr.com