20 సంవత్సరాలకు పైగా మేము HTTP ప్రోటోకాల్‌ని ఉపయోగించి వెబ్ పేజీలను చూస్తున్నాము. చాలా మంది వినియోగదారులు ఇది ఏమిటి మరియు ఇది ఎలా పని చేస్తుంది అనే దాని గురించి కూడా ఆలోచించరు. HTTP క్రింద ఎక్కడో TLS ఉందని మరియు దాని క్రింద TCP ఉందని, దాని క్రింద IP అని ఇతరులకు తెలుసు. మరికొందరు - మతవిశ్వాసులు - TCP అనేది గతానికి సంబంధించినది అని నమ్ముతారు; వారు వేగవంతమైన, మరింత విశ్వసనీయమైన మరియు సురక్షితమైనదాన్ని కోరుకుంటారు. కానీ కొత్త ఆదర్శ ప్రోటోకాల్‌ను కనుగొనే వారి ప్రయత్నాలలో, వారు 80ల సాంకేతికతకు తిరిగి వచ్చారు మరియు దానిపై వారి ధైర్యమైన కొత్త ప్రపంచాన్ని నిర్మించడానికి ప్రయత్నిస్తున్నారు.
కొద్దిగా చరిత్ర: HTTP/1.1
1997లో, టెక్స్ట్ ఇన్ఫర్మేషన్ ఎక్స్ఛేంజ్ ప్రోటోకాల్ HTTP వెర్షన్ 1.1 దాని స్వంత RFCని పొందింది. ఆ సమయంలో, ప్రోటోకాల్ అనేక సంవత్సరాలు బ్రౌజర్లచే ఉపయోగించబడింది మరియు కొత్త ప్రమాణం మరో పదిహేను వరకు కొనసాగింది. ప్రోటోకాల్ అభ్యర్థన-ప్రతిస్పందన సూత్రంపై మాత్రమే పని చేస్తుంది మరియు ప్రధానంగా టెక్స్ట్ సమాచారాన్ని ప్రసారం చేయడానికి ఉద్దేశించబడింది.
HTTP అనేది TCP ప్రోటోకాల్ పైన రన్ అయ్యేలా రూపొందించబడింది, ప్యాకెట్లు వాటి గమ్యస్థానానికి విశ్వసనీయంగా డెలివరీ చేయబడతాయని నిర్ధారిస్తుంది. ఎండ్‌పాయింట్‌ల మధ్య విశ్వసనీయ కనెక్షన్‌ని ఏర్పాటు చేయడం మరియు నిర్వహించడం ద్వారా మరియు ట్రాఫిక్‌ను విభాగాలుగా విభజించడం ద్వారా TCP పనిచేస్తుంది. విభాగాలు వాటి స్వంత క్రమ సంఖ్య మరియు చెక్‌సమ్‌ని కలిగి ఉంటాయి. అకస్మాత్తుగా సెగ్మెంట్లలో ఒకటి రాకపోతే లేదా సరికాని చెక్‌సమ్‌తో వచ్చినట్లయితే, కోల్పోయిన సెగ్మెంట్ పునరుద్ధరించబడే వరకు ప్రసారం ఆగిపోతుంది.
HTTP/1.0లో, ప్రతి అభ్యర్థన తర్వాత TCP కనెక్షన్ మూసివేయబడింది. ఇది చాలా వ్యర్థమైనది, ఎందుకంటే... TCP కనెక్షన్‌ని ఏర్పాటు చేయడం (3-వే-హ్యాండ్‌షేక్) నెమ్మదిగా జరిగే ప్రక్రియ. HTTP/1.1 కీప్-ఎలైవ్ మెకానిజమ్‌ను పరిచయం చేసింది, ఇది బహుళ అభ్యర్థనల కోసం ఒక కనెక్షన్‌ని మళ్లీ ఉపయోగించేందుకు మిమ్మల్ని అనుమతిస్తుంది. అయినప్పటికీ, ఇది సులభంగా అడ్డంకిగా మారవచ్చు కాబట్టి, HTTP/1.1 యొక్క వివిధ అమలులు ఒకే హోస్ట్‌కు బహుళ TCP కనెక్షన్‌లను తెరవడానికి అనుమతిస్తాయి. ఉదాహరణకు, Chrome మరియు Firefox యొక్క ఇటీవలి సంస్కరణలు గరిష్టంగా ఆరు కనెక్షన్‌లను అనుమతిస్తాయి.
ఎన్క్రిప్షన్ ఇతర ప్రోటోకాల్‌లకు కూడా వదిలివేయబడాలి మరియు దీని కోసం, TLS ప్రోటోకాల్ TCP ద్వారా ఉపయోగించబడింది, ఇది డేటాను విశ్వసనీయంగా రక్షించింది, కానీ కనెక్షన్‌ని స్థాపించడానికి అవసరమైన సమయాన్ని మరింత పెంచింది. ఫలితంగా, హ్యాండ్‌షేక్ ప్రక్రియ ఇలా కనిపించడం ప్రారంభమైంది:
క్లౌడ్‌ఫ్లేర్ ఇలస్ట్రేషన్
అందువలన HTTP/1.1 అనేక సమస్యలను కలిగి ఉంది:
- నెమ్మదిగా కనెక్షన్ సెటప్.
- డేటా టెక్స్ట్ రూపంలో ప్రసారం చేయబడుతుంది, అంటే చిత్రాలు, వీడియోలు మరియు ఇతర నాన్-టెక్స్ట్ సమాచారం యొక్క ప్రసారం అసమర్థంగా ఉంటుంది.
- ఒక అభ్యర్థన కోసం ఒక TCP కనెక్షన్ ఉపయోగించబడుతుంది, అంటే ఇతర అభ్యర్థనలు తప్పనిసరిగా మరొక కనెక్షన్‌ని కనుగొనాలి లేదా ప్రస్తుత అభ్యర్థన దానిని విడుదల చేసే వరకు వేచి ఉండాలి.
- పుల్ మోడల్‌కు మాత్రమే మద్దతు ఉంది. సర్వర్-పుష్ గురించి ప్రమాణంలో ఏమీ లేదు.
- శీర్షికలు వచనంలో ప్రసారం చేయబడతాయి.
సర్వర్-పుష్ కనీసం WebSocket ప్రోటోకాల్ ఉపయోగించి అమలు చేయబడితే, మిగిలిన సమస్యలను మరింత తీవ్రంగా పరిష్కరించవలసి ఉంటుంది.
కొద్దిగా ఆధునికత: HTTP/2
2012లో, Google SPDY ("స్పీడీ" అని ఉచ్ఛరిస్తారు) ప్రోటోకాల్‌పై పని చేయడం ప్రారంభించింది. ప్రోటోకాల్ HTTP/1.1 యొక్క ప్రధాన సమస్యలను పరిష్కరించడానికి రూపొందించబడింది మరియు అదే సమయంలో వెనుకబడిన అనుకూలతను కొనసాగించడానికి ఉద్దేశించబడింది. 2015లో, IETF వర్కింగ్ గ్రూప్ SPDY ప్రోటోకాల్ ఆధారంగా HTTP/2 స్పెసిఫికేషన్‌ను పరిచయం చేసింది. HTTP/2లో తేడాలు ఇక్కడ ఉన్నాయి:
- బైనరీ సీరియలైజేషన్.
- ఒకే TCP కనెక్షన్‌లో బహుళ HTTP అభ్యర్థనలను మల్టీప్లెక్సింగ్ చేయడం.
- సర్వర్-పుష్ అవుట్ ఆఫ్ బాక్స్ (వెబ్‌సాకెట్ లేకుండా).
ప్రోటోకాల్ ఒక పెద్ద ముందడుగు. అతను గట్టిగా మరియు బహుళ TCP కనెక్షన్‌ల సృష్టి అవసరం లేదు: ఒక హోస్ట్‌కి సంబంధించిన అన్ని అభ్యర్థనలు ఒకటిగా మల్టీప్లెక్స్ చేయబడతాయి. అంటే, ఒక కనెక్షన్‌లో అనేక స్ట్రీమ్‌లు అని పిలవబడేవి ఉన్నాయి, వీటిలో ప్రతి దాని స్వంత ID ఉంటుంది. బోనస్ బాక్స్డ్ సర్వర్-పుష్.
అయితే, మల్టీప్లెక్సింగ్ మరో కీలక సమస్యకు దారితీస్తుంది. మేము ఒక సర్వర్‌కు 5 అభ్యర్థనలను అసమకాలికంగా అమలు చేస్తున్నామని ఊహించండి. HTTP/2ని ఉపయోగిస్తున్నప్పుడు, ఈ అభ్యర్థనలన్నీ ఒకే TCP కనెక్షన్‌లో నిర్వహించబడతాయి, అంటే ఏదైనా అభ్యర్థన యొక్క సెగ్మెంట్లలో ఒకటి పోయినట్లయితే లేదా తప్పుగా స్వీకరించబడినట్లయితే, అన్ని అభ్యర్థనలు మరియు ప్రతిస్పందనల ప్రసారం పోయిన సెగ్మెంట్ వరకు ఆగిపోతుంది పునరుద్ధరించబడింది. సహజంగానే, కనెక్షన్ నాణ్యత అధ్వాన్నంగా ఉంటే, నెమ్మదిగా HTTP/2 పనిచేస్తుంది. , కోల్పోయిన ప్యాకెట్లు అన్ని ప్యాకెట్‌లలో 2% ఖాతాలో ఉన్న పరిస్థితుల్లో, బ్రౌజర్‌లోని HTTP/1.1 ఒకటి కంటే 2 కనెక్షన్‌లను తెరవడం వల్ల HTTP/6 కంటే మెరుగ్గా పని చేస్తుంది.
ఈ సమస్యను "హెడ్-ఆఫ్-లైన్ బ్లాకింగ్" అని పిలుస్తారు మరియు దురదృష్టవశాత్తు, TCPని ఉపయోగిస్తున్నప్పుడు దాన్ని పరిష్కరించడం సాధ్యం కాదు.
డేనియల్ స్టెయిన్‌బర్గ్ ద్వారా ఇలస్ట్రేషన్
ఫలితంగా, HTTP/2 ప్రమాణం యొక్క డెవలపర్లు గొప్ప పని చేసారు మరియు OSI మోడల్ యొక్క అప్లికేషన్ లేయర్‌లో చేయగలిగే దాదాపు ప్రతిదీ చేసారు. ట్రాన్స్‌పోర్ట్ లేయర్‌కి దిగి, కొత్త ట్రాన్స్‌పోర్ట్ ప్రోటోకాల్‌ను కనిపెట్టడానికి ఇది సమయం.
మాకు కొత్త ప్రోటోకాల్ అవసరం: UDP vs TCP
పూర్తిగా కొత్త ట్రాన్స్‌పోర్ట్ లేయర్ ప్రోటోకాల్‌ని అమలు చేయడం నేటి వాస్తవాల్లో అసాధ్యమైన పని అని చాలా త్వరగా స్పష్టమైంది. వాస్తవం ఏమిటంటే హార్డ్‌వేర్ లేదా మిడిల్-బాక్స్‌లు (రౌటర్లు, ఫైర్‌వాల్‌లు, NAT సర్వర్‌లు...) రవాణా పొర గురించి తెలుసు మరియు వాటికి కొత్తవి నేర్పడం చాలా కష్టమైన పని. అదనంగా, రవాణా ప్రోటోకాల్‌లకు మద్దతు ఆపరేటింగ్ సిస్టమ్‌ల కెర్నల్‌లో నిర్మించబడింది మరియు కెర్నలు కూడా మార్చడానికి చాలా ఇష్టపడవు.
మరియు ఇక్కడ ఒకరు ఒకరి చేతులను పైకి లేపి, “మేము, ప్రాధాన్యత మరియు వేశ్యలతో కొత్త HTTP/3ని కనిపెట్టాము, అయితే ఇది అమలు చేయడానికి 10-15 సంవత్సరాలు పడుతుంది (ఈ సమయం తర్వాత చాలా హార్డ్‌వేర్ ఉంటుంది భర్తీ చేయబడింది),” కానీ మరొకటి లేదు కాబట్టి UDP ప్రోటోకాల్‌ను ఉపయోగించడం అనేది స్పష్టమైన ఎంపిక. అవును, అవును, మేము తొంభైల చివరలో మరియు XNUMXల ప్రారంభంలో LANలో ఫైల్‌లను విసిరేందుకు ఉపయోగించిన అదే ప్రోటోకాల్. దాదాపు అన్ని నేటి హార్డ్‌వేర్ దానితో పని చేయగలదు.
TCP కంటే UDP యొక్క ప్రయోజనాలు ఏమిటి? అన్నింటిలో మొదటిది, హార్డ్‌వేర్‌కు తెలిసిన ట్రాన్స్‌పోర్ట్ లేయర్ సెషన్ మాకు లేదు. ఇది ఎండ్‌పాయింట్‌లపై సెషన్‌ను మనమే నిర్ణయించుకోవడానికి మరియు అక్కడ వైరుధ్యాలను పరిష్కరించడానికి అనుమతిస్తుంది. అంటే, మేము ఒకటి లేదా అనేక సెషన్‌లకు (TCPలో వలె) పరిమితం కాకుండా, మనకు అవసరమైనన్ని వాటిని సృష్టించవచ్చు. రెండవది, TCP ద్వారా కంటే UDP ద్వారా డేటా ట్రాన్స్‌మిషన్ వేగంగా ఉంటుంది. అందువలన, సిద్ధాంతపరంగా, మేము HTTP/2లో సాధించిన ప్రస్తుత స్పీడ్ సీలింగ్‌ను విచ్ఛిన్నం చేయవచ్చు.
అయినప్పటికీ, UDP విశ్వసనీయ డేటా ప్రసారానికి హామీ ఇవ్వదు. నిజానికి, మేము కేవలం ప్యాకెట్లను పంపుతున్నాము, అవతలి వైపు వాటిని స్వీకరిస్తారని ఆశిస్తున్నాము. అందుకోలేదా? సరే, అదృష్టం లేదు... పెద్దల కోసం వీడియోలను ప్రసారం చేయడానికి ఇది సరిపోతుంది, కానీ మరింత తీవ్రమైన విషయాల కోసం మీకు విశ్వసనీయత అవసరం, అంటే మీరు UDP పైన మరేదైనా చుట్టాలి.
HTTP/2 మాదిరిగా, Googleలో 2012లో కొత్త ప్రోటోకాల్‌ను రూపొందించే పని ప్రారంభమైంది, అంటే SPDYలో పని ప్రారంభమైన అదే సమయంలో. 2013లో, జిమ్ రోస్కిండ్ సాధారణ ప్రజలకు అందించారు , మరియు ఇప్పటికే 2015లో IETFలో ప్రామాణీకరణ కోసం ఇంటర్నెట్ డ్రాఫ్ట్ ప్రవేశపెట్టబడింది. ఇప్పటికే ఆ సమయంలో, Google వద్ద Roskind అభివృద్ధి చేసిన ప్రోటోకాల్ ప్రమాణం నుండి చాలా భిన్నంగా ఉంది, కాబట్టి Google సంస్కరణను gQUIC అని పిలవడం ప్రారంభమైంది.
QUIC అంటే ఏమిటి
ముందుగా, ఇదివరకే చెప్పినట్లుగా, ఇది UDPపై రేపర్. UDP పైన QUIC కనెక్షన్ పెరుగుతుంది, దీనిలో, HTTP/2తో సారూప్యతతో, అనేక స్ట్రీమ్‌లు ఉండవచ్చు. ఈ స్ట్రీమ్‌లు ఎండ్ పాయింట్‌లలో మాత్రమే ఉంటాయి మరియు స్వతంత్రంగా అందించబడతాయి. ఒక స్ట్రీమ్‌లో ప్యాకెట్ నష్టం జరిగితే, అది ఇతరులపై ప్రభావం చూపదు.
డేనియల్ స్టెయిన్‌బర్గ్ ద్వారా ఇలస్ట్రేషన్
రెండవది, ఎన్క్రిప్షన్ ఇకపై ప్రత్యేక స్థాయిలో అమలు చేయబడదు, కానీ ప్రోటోకాల్‌లో చేర్చబడుతుంది. ఇది ఒకే హ్యాండ్‌షేక్‌లో కనెక్షన్‌ని ఏర్పాటు చేయడానికి మరియు పబ్లిక్ కీలను మార్పిడి చేసుకోవడానికి మిమ్మల్ని అనుమతిస్తుంది మరియు తెలివైన 0-RTT హ్యాండ్‌షేక్ మెకానిజంను ఉపయోగించడానికి మరియు హ్యాండ్‌షేక్ ఆలస్యాన్ని పూర్తిగా నివారించడానికి మిమ్మల్ని అనుమతిస్తుంది. అదనంగా, ఇప్పుడు వ్యక్తిగత డేటా ప్యాకెట్లను గుప్తీకరించడం సాధ్యమవుతుంది. ఇది స్ట్రీమ్ నుండి డేటాను స్వీకరించడం పూర్తయ్యే వరకు వేచి ఉండకుండా, స్వీకరించిన ప్యాకెట్లను స్వతంత్రంగా డీక్రిప్ట్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. TCPలో ఈ ఆపరేషన్ విధానం సాధారణంగా అసాధ్యం, ఎందుకంటే TLS మరియు TCP ఒకదానికొకటి స్వతంత్రంగా పనిచేశాయి మరియు TCP డేటా ఏ ముక్కలుగా కత్తిరించబడుతుందో TLSకి తెలియదు. అందువల్ల, అతను తన విభాగాలను సిద్ధం చేయలేకపోయాడు, తద్వారా అవి ఒకదానికొకటి TCP విభాగాలకు సరిపోతాయి మరియు స్వతంత్రంగా డీక్రిప్ట్ చేయబడతాయి. ఈ మెరుగుదలలన్నీ TCPతో పోల్చితే QUIC జాప్యాన్ని తగ్గించడానికి అనుమతిస్తాయి.
మూడవదిగా, లైట్ స్ట్రీమింగ్ భావన క్లయింట్ యొక్క IP చిరునామా నుండి కనెక్షన్‌ని విడదీయడానికి మిమ్మల్ని అనుమతిస్తుంది. ఇది ముఖ్యమైనది, ఉదాహరణకు, క్లయింట్ ఒక Wi-Fi యాక్సెస్ పాయింట్ నుండి మరొకదానికి మారినప్పుడు, దాని IPని మారుస్తుంది. ఈ సందర్భంలో, TCPని ఉపయోగిస్తున్నప్పుడు, సుదీర్ఘమైన ప్రక్రియ జరుగుతుంది, ఈ సమయంలో ఇప్పటికే ఉన్న TCP కనెక్షన్‌ల సమయం ముగిసింది మరియు కొత్త IP నుండి కొత్త కనెక్షన్లు సృష్టించబడతాయి. QUIC విషయంలో, క్లయింట్ పాత స్ట్రీమ్ IDతో కొత్త IP నుండి సర్వర్‌కు ప్యాకెట్లను పంపడం కొనసాగిస్తుంది. ఎందుకంటే స్ట్రీమ్ ID ఇప్పుడు ప్రత్యేకమైనది మరియు మళ్లీ ఉపయోగించబడదు; క్లయింట్ IPని మార్చిందని, పోయిన ప్యాకెట్లను మళ్లీ పంపిందని మరియు కొత్త చిరునామాలో కమ్యూనికేషన్‌ను కొనసాగిస్తున్నట్లు సర్వర్ అర్థం చేసుకుంది.
నాల్గవది, QUIC అప్లికేషన్ స్థాయిలో అమలు చేయబడుతుంది, ఆపరేటింగ్ సిస్టమ్ స్థాయిలో కాదు. ఇది, ఒక వైపు, ప్రోటోకాల్‌లో త్వరగా మార్పులు చేయడానికి మిమ్మల్ని అనుమతిస్తుంది, ఎందుకంటే అప్‌డేట్ పొందడానికి, మీరు కొత్త OS వెర్షన్ కోసం వేచి ఉండకుండా లైబ్రరీని అప్‌డేట్ చేయాలి. మరోవైపు, ఇది ప్రాసెసర్ వినియోగంలో బలమైన పెరుగుదలకు దారితీస్తుంది.
చివరకు, ముఖ్యాంశాలు. హెడర్ కంప్రెషన్ అనేది QUIC మరియు gQUIC మధ్య తేడా ఉన్న వాటిలో ఒకటి. దీనికి ఎక్కువ సమయం కేటాయించడంలో నాకు అర్థం లేదు, స్టాండర్డైజేషన్ కోసం సమర్పించిన సంస్కరణలో, హెడర్ కంప్రెషన్ HTTP/2లో హెడర్ కంప్రెషన్‌కు వీలైనంత సారూప్యంగా ఉందని నేను చెప్తాను. మీరు మరింత చదవగలరు .
ఇది ఎంత వేగంగా ఉంటుంది?
ఇది కష్టమైన ప్రశ్న. వాస్తవం ఏమిటంటే, మనకు ఒక ప్రమాణం ఉన్నంత వరకు, ప్రత్యేకంగా కొలవడానికి ఏమీ లేదు. 2013 నుండి మరియు 2016లో gQUICని ఉపయోగిస్తున్న Google నుండి వచ్చిన గణాంకాలు మా వద్ద ఉన్న ఏకైక గణాంకాలు కావచ్చు. Chrome బ్రౌజర్ నుండి వారి సర్వర్‌లకు వెళ్లే దాదాపు 90% ట్రాఫిక్ ఇప్పుడు QUICని ఉపయోగిస్తోంది. అదే ప్రెజెంటేషన్‌లో, gQUIC ద్వారా పేజీలు దాదాపు 5% వేగంగా లోడ్ అవుతాయని మరియు TCPతో పోలిస్తే వీడియో స్ట్రీమింగ్‌లో 30% తక్కువ నత్తిగా మాట్లాడుతున్నాయని వారు నివేదించారు.
2017లో, అరాష్ మొలవి కఖ్కీ నేతృత్వంలోని పరిశోధకుల బృందం ప్రచురించింది TCPతో పోలిస్తే gQUIC పనితీరును అధ్యయనం చేయడానికి.
నెట్‌వర్క్ ప్యాకెట్‌ల మిక్సింగ్‌లో అస్థిరత, ఛానల్ బ్యాండ్‌విడ్త్‌కు అత్యాశ (అన్యాయం) మరియు చిన్న (10 kb వరకు) వస్తువులను నెమ్మదిగా బదిలీ చేయడం వంటి gQUIC యొక్క అనేక బలహీనతలను అధ్యయనం వెల్లడించింది. అయితే, రెండోది 0-RTTని ఉపయోగించడం ద్వారా భర్తీ చేయవచ్చు. అధ్యయనం చేసిన అన్ని ఇతర సందర్భాలలో, TCPతో పోలిస్తే gQUIC వేగం పెరుగుదలను చూపింది. ఇక్కడ నిర్దిష్ట సంఖ్యల గురించి మాట్లాడటం కష్టం. చదవడం మంచిది లేదా .
ఇక్కడ ఈ డేటా ప్రత్యేకంగా gQUIC గురించి చెప్పాలి మరియు ఇది అభివృద్ధి చేయబడుతున్న ప్రమాణానికి సంబంధించినది కాదు. QUIC కోసం ఏమి జరుగుతుంది: ఇది ఇప్పటికీ రహస్యం, కానీ gQUICలో గుర్తించబడిన బలహీనతలు పరిగణనలోకి తీసుకోబడతాయి మరియు సరిదిద్దబడతాయి.
భవిష్యత్తు గురించి కొంచెం: HTTP/3 గురించి ఏమిటి?
కానీ ఇక్కడ ప్రతిదీ స్పష్టంగా ఉంది: API ఏ విధంగానూ మారదు. HTTP/2లో ఉన్నట్లే అన్నీ అలాగే ఉంటాయి. సరే, API అలాగే ఉన్నట్లయితే, QUIC రవాణాకు మద్దతు ఇచ్చే బ్యాకెండ్‌లో లైబ్రరీ యొక్క తాజా వెర్షన్‌ని ఉపయోగించడం ద్వారా HTTP/3కి పరివర్తనను పరిష్కరించాలి. నిజమే, మీరు కొంతకాలం పాటు HTTP యొక్క పాత వెర్షన్‌లలో ఫాల్‌బ్యాక్‌ను ఉంచవలసి ఉంటుంది, ఎందుకంటే UDPకి పూర్తి పరివర్తన కోసం ప్రస్తుతం ఇంటర్నెట్ సిద్ధంగా లేదు.
ఇప్పటికే ఎవరు మద్దతు ఇస్తున్నారు
ఇక్కడ ఇప్పటికే ఉన్న QUIC అమలులు. ప్రమాణం లేనప్పటికీ, జాబితా చెడ్డది కాదు.
ఉత్పత్తి విడుదలలో QUICకి ప్రస్తుతం ఏ బ్రౌజర్ మద్దతు ఇవ్వదు. క్రోమ్‌లో HTTP/3కి మద్దతు చేర్చబడినట్లు ఇటీవల సమాచారం ఉంది, కానీ ఇప్పటివరకు కానరీలో మాత్రమే.
బ్యాకెండ్‌లలో, HTTP/3 మాత్రమే మద్దతు ఇస్తుంది и , కానీ ఇప్పటికీ ప్రయోగాత్మకం. NGINX వసంత 2019 చివరిలో , వారు HTTP/3 మద్దతుపై పని చేయడం ప్రారంభించారు, కానీ ఇంకా పూర్తి చేయలేదు.
సమస్యలు ఏమిటి?
మీరు మరియు నేను వాస్తవ ప్రపంచంలో జీవిస్తున్నాము, ఇక్కడ ప్రతిఘటనను ఎదుర్కోకుండా పెద్ద సాంకేతికత ప్రజలకు చేరుకోదు మరియు QUIC మినహాయింపు కాదు.
అత్యంత ముఖ్యమైన విషయం ఏమిటంటే, మీరు "https://" అనేది TCP పోర్ట్ 443కి దారితీస్తుందనేది ఇకపై వాస్తవం కాదని బ్రౌజర్‌కి వివరించాల్సిన అవసరం ఉంది. TCP అస్సలు ఉండకపోవచ్చు. దీని కోసం Alt-Svc హెడర్ ఉపయోగించబడుతుంది. ఈ వెబ్‌సైట్ అటువంటి మరియు అటువంటి చిరునామాలో అటువంటి ప్రోటోకాల్‌లో కూడా అందుబాటులో ఉందని బ్రౌజర్‌కి తెలియజేయడానికి ఇది మిమ్మల్ని అనుమతిస్తుంది. సిద్ధాంతపరంగా, ఇది ఆకర్షణీయంగా పని చేయాలి, కానీ ఆచరణలో మేము UDPని, ఉదాహరణకు, DDoS దాడులను నివారించడానికి ఫైర్‌వాల్‌పై నిషేధించబడవచ్చు.
UDP నిషేధించబడనప్పటికీ, క్లయింట్ IP చిరునామా ద్వారా TCP సెషన్‌ను నిర్వహించడానికి కాన్ఫిగర్ చేయబడిన NAT రౌటర్ వెనుక ఉండవచ్చు మరియు దీని నుండి మేము హార్డ్‌వేర్ సెషన్ లేని UDPని ఉపయోగిస్తాము, NAT కనెక్షన్‌ని కలిగి ఉండదు మరియు QUIC సెషన్‌ను ఉపయోగిస్తాము .
ఇంటర్నెట్ కంటెంట్‌ను ప్రసారం చేయడానికి UDP ఇంతకు ముందు ఉపయోగించబడకపోవడం మరియు హార్డ్‌వేర్ తయారీదారులు ఇది ఎప్పటికీ జరుగుతుందని ఊహించలేకపోవడం వల్ల ఈ సమస్యలన్నీ ఉన్నాయి. అదే విధంగా, QUIC పని చేయడానికి వారి నెట్‌వర్క్‌లను ఎలా సరిగ్గా కాన్ఫిగర్ చేయాలో నిర్వాహకులు ఇంకా అర్థం చేసుకోలేదు. ఈ పరిస్థితి క్రమంగా మారుతుంది మరియు ఏదైనా సందర్భంలో, అటువంటి మార్పులు కొత్త రవాణా పొర ప్రోటోకాల్ అమలు కంటే తక్కువ సమయం పడుతుంది.
అదనంగా, ఇప్పటికే వివరించినట్లుగా, QUIC CPU వినియోగాన్ని బాగా పెంచుతుంది. డేనియల్ స్టెన్‌బర్గ్ ప్రాసెసర్ మూడు రెట్లు పెరుగుతుంది.
HTTP/3 ఎప్పుడు వస్తుంది?
ప్రామాణిక మే 2020 నాటికి, కానీ జూలై 2019కి షెడ్యూల్ చేయబడిన పత్రాలు ప్రస్తుతానికి అసంపూర్తిగా ఉన్నందున, తేదీ చాలావరకు వెనక్కి నెట్టబడుతుందని మేము చెప్పగలం.
సరే, Google 2013 నుండి దాని gQUIC అమలును ఉపయోగిస్తోంది. మీరు Google శోధన ఇంజిన్‌కు పంపబడిన HTTP అభ్యర్థనను చూస్తే, మీరు దీన్ని చూస్తారు:
కనుగొన్న
QUIC ఇప్పుడు క్రూడ్, కానీ చాలా ఆశాజనకమైన సాంకేతికతలా కనిపిస్తోంది. గత 20 సంవత్సరాలలో, ట్రాన్స్‌పోర్ట్ లేయర్ ప్రోటోకాల్‌ల యొక్క అన్ని ఆప్టిమైజేషన్‌లు ప్రధానంగా TCP, QUICకి సంబంధించినవి, ఇది చాలా సందర్భాలలో పనితీరులో గెలుస్తుంది, ఇప్పటికే చాలా బాగుంది.
అయితే, రాబోయే కొన్నేళ్లలో పరిష్కరించబడని సమస్యలు ఇంకా ఉన్నాయి. ఎవరూ అప్‌డేట్ చేయడానికి ఇష్టపడని హార్డ్‌వేర్ ఉన్నందున ప్రక్రియ ఆలస్యం కావచ్చు, అయినప్పటికీ, అన్ని సమస్యలు చాలా పరిష్కరించదగినవిగా కనిపిస్తాయి మరియు త్వరగా లేదా తరువాత మనందరికీ HTTP/3 ఉంటుంది.
భవిష్యత్తు కేవలం మూలలో ఉంది!
మూలం: www.habr.com