ナヌザヌがgoogle.comをブラりザヌに駆動するず実際に䜕が起こるか



この蚘事は、むンタビュヌの叀い質問に答えようずする詊みです。「アドレスバヌにgoogle.comず入力しおEnterキヌを抌すずどうなりたすか」1぀の詳现を逃さずに、できるだけ詳现に把握しようずしたす。

泚この 出版物は、 䜕が起こるか...リポゞトリの内容に基づいおいたす

提瀺されたコンテンツには倚数の甚語が豊富にあり、それらの䞀郚の翻蚳にはさたざたな䞍正確さがありたす。 翻蚳に誀りがある堎合は、個人的なメッセヌゞを曞いおください。修正したす。

翻蚳をGitHubリポゞトリに転送し、玠材の䜜成者にプルリク゚ストを送信したした。線集はテキストのたたにしおください。䞀緒にすれば、倧幅に改善できたす。

1. gキヌを抌したす


蚘事の残りの郚分には、物理​​キヌボヌドずオペレヌティングシステムの䞭断に関する情報が含たれおいたす。 しかし、倚くのこずが起こりたす。これに加えお、「g」キヌを抌すず、ブラりザがむベントを受け取り、自動眮換メカニズムが開始されたす。 ブラりザのアルゎリズムずそのモヌド「シヌクレット」機胜が有効かどうかに応じお、URLバヌの䞋のドロップダりンりィンドりで、ナヌザヌは自動眮換のための特定の数のオプションを提䟛されたす。

ほずんどの自動眮換アルゎリズムは、怜玢履歎ず残っおいるブックマヌクに基づいお掚奚事項をランク付けしたす。 䞀郚のブラりザ䟋Rockmeltでは、Facebookの友達プロフィヌルも提䟛しおいたす。 ナヌザヌがアドレスバヌに「google.com」ず入力する堎合、䞊蚘のいずれも重芁ではありたせんが、それでも倧量のコヌドが実行され、新しい文字が印刷されるたびに掚奚事項が曎新されたす。 おそらくブラりザは、ナヌザヌがアドレス党䜓をヒットする前に、google.comにアクセスするこずを提案したす。

2. Enterキヌを最埌たで抌したす


特定のれロポむントずしお、キヌボヌドのEnterキヌが最埌たで抌されお䞋の䜍眮にある瞬間を遞択できたす。 この時点で、このキヌの電気回路が閉じ、少量の電流がキヌボヌド配線図に送られたす。この配線図では、各キヌスむッチの状態をスキャンし、信号を敎数キヌコヌドこの堎合は13に倉換したす。 キヌボヌドコントロヌラヌは、コンピュヌタヌに送信するためにキヌコヌドを倉換したす。 原則ずしお、転送はUSBたたはBluetooth経由で、キヌボヌドがPS / 2たたはADBコネクタを䜿甚しおコンピュヌタヌに接続される前に行われたす。

USBキヌボヌドの堎合


仮想キヌボヌドタッチスクリヌンの堎合


2.1䞭断が発生した[USBキヌボヌドではない]


キヌボヌドは信号を「割り蟌み芁求ラむン」IRQに送信し、その埌、割り蟌みコントロヌラヌによっお「割り蟌みベクトル」敎数にマッピングされたす。 プロセッサは、「割り蟌み蚘述子テヌブル」IDTを䜿甚しお、割り蟌みベクトルをカヌネルの機胜「割り蟌みハンドラヌ」にマップしたす。 割り蟌みが発生するず、プロセッサCPUはIDTを割り蟌みベクタヌで曎新し、察応するハンドラヌを起動したす。 したがっお、コアが機胜したす。

2.2Windowsの堎合 WM_KEYDOWNメッセヌゞがアプリケヌションに送信されたした


HIDは、抌されたキヌむベントをKBDHID.sysドラむバヌに送信し、ドラむバヌはそれをスキャンコヌドに倉換したす 。 この特定のケヌスでは、スキャンコヌドはVK_RETURN  0x0D です。 KDBHID.sysドラむバヌは、 KBDCLASS.sysドラむバヌキヌボヌドクラスドラむバヌず通信したす。 圌は、すべおのキヌボヌド入力を安党に凊理する責任がありたす。 将来、このドラむバヌはWin32K.sys呌び出しWin32K.sys むンストヌルされおいるサヌドパヌティのキヌボヌドフィルタヌを介したメッセヌゞ送信の可胜性の埌。 これはすべおカヌネルモヌドで行われたす。

Win32K.sysは、 GetForegroundWindow()関数を䜿甚しお、珟圚アクティブなりィンドりを刀別したす。 このAPIは、ブラりザのアドレスバヌりィンドりの凊理を提䟛したす。 次に、Windowsのメむンの「メッセヌゞポンプ」がSendMessage(hWnd, WM_KEYDOWN, VK_RETURN, lParam)呌び出したす。 lParamは、キヌストロヌクに関する詳现情報を瀺すビットマスクです。再詊行カりンタヌこの堎合は0、珟圚のスキャンコヌドOEMに䟝存する堎合がありたすが、 VK_RETURNは通垞これに䟝存したせん、情報远加のキヌたずえば、Alt、Shift、Ctrl-この堎合はそうではありたせんでしたおよびその他のデヌタ。

Windows APIには、特定のりィンドりハンドラヌ hWnd のメッセヌゞをキュヌにSendMessage関数がありたす。 その埌、 hWndハンドラヌに割り圓おられたメむンのメッセヌゞ凊理関数 WindowProc がhWndれ、キュヌ内のすべおのメッセヌゞが凊理されたす。

珟圚アクティブなりィンドり hWnd は凊理の制埡であり、この堎合、WindowsProcにはWM_KEYDOWNメッセヌゞのハンドラヌがWM_KEYDOWNたす。 このコヌドは、 SendMessage (wParam)に含たれる3番目のパラメヌタヌを調べ、 VK_RETURNであるため、ナヌザヌがEnterキヌを抌したこずを理解したす。

2.3OS Xの堎合 NSEVent KeyDownがアプリケヌションに送信されたした


割り蟌み信号は、キヌボヌドI / Oキットドラむバヌで割り蟌みむベントをトリガヌしたす。 ドラむバヌは信号をキヌボヌドコヌドに倉換し、それがWindowServerずいうOS Xプロセスに枡されたす。 その結果、 WindowsServerは、むベントがキュヌに入れられおいるMachポヌトを介しお、適切なアクティブたたは「リスニング」アプリケヌションにむベントを枡したす。 その埌、 mach_ipc_dispatch関数を呌び出すのに十分な特暩を持぀スレッドによっお、このキュヌからむベントを読み取るこずができたす。 ほずんどの堎合、これは発生し、 NSEventype KeyDown NSEventを介しおメむンNSApplicationルヌプを䜿甚しお凊理されたす。

2.4GNU / Linuxの堎合Xorgサヌバヌはキヌボヌドコヌドをリッスンしたす


グラフィカルXサヌバヌの堎合、䞀般的なevdevむベントドラむバヌがキヌストロヌクの受信に䜿甚されたす。 キヌボヌドコヌドをスキャンコヌドに再割り圓おするには、特別なルヌルずXサヌバヌカヌドを䜿甚したす。 抌されたキヌのスキャンコヌドのマッピングが完了するず、Xサヌバヌはその文字をりィンドりマネヌゞャヌDWM、metacity、i3に送信し、りィンドりマネヌゞャヌはその文字をアクティブりィンドりに送信したす。 文字を受け取ったりィンドりのグラフィカルAPIは、目的のフィヌルドに察応するフォント文字を印刷したす。

3. URL解析


ブラりザには、次のURL情報がありたす。

プロトコル「HTTP」
ハむパヌテキスト転送プロトコルを䜿甚する

リ゜ヌス「/」
メむンむンデックスペヌゞを衚瀺

3.1これはURLですか、それずも怜玢ク゚リですか


ナヌザヌがプロトコルたたはドメむン名を入力しない堎合、ブラりザヌはナヌザヌが入力した内容をデフォルトの怜玢゚ンゞンに「フィヌド」したす。 倚くの堎合、特別なテキストがURLに远加されるため、情報が特定のブラりザヌのURLバヌから送信されるこずを怜玢゚ンゞンが理解できたす。

3.2 HSTSチェックリスト



3.3非ASCII Unicode文字のホスト名ぞの倉換



4. DNSの定矩



4.1 ARP芁求を送信するプロセス


ブロヌドキャストARP芁求を送信するには、タヌゲットIPアドレスず、ARP芁求の送信に䜿甚されるむンタヌフェむスのMACアドレスを芋぀ける必芁がありたす。

各宛先IPアドレスのARPキャッシュがチェックされたす-アドレスがキャッシュ内にある堎合、ラむブラリ関数は結果を返したす Target IP = MAC 。

キャッシュ゚ントリがない堎合


ARP芁求

Sender MAC: interface:mac:address:here
Sender IP: interface.ip.goes.here
Target MAC: FF:FF:FF:FF:FF:FF (Broadcast)
Target IP: target.ip.goes.here

コンピュヌタヌずルヌタヌルヌタヌの間にあるハヌドりェアの皮類に応じお

盎接接続


それらの間ハブハブ


それらの間にスむッチスむッチ


ARP回答

Sender MAC: target:mac:address:here
Sender IP: target.ip.goes.here
Target MAC: interface:mac:address:here
Target IP: interface.ip.goes.here

これで、ネットワヌクラむブラリには、DNSサヌバヌたたはデフォルトゲヌトりェむのIPアドレスがあり、ドメむン名の解決に䜿甚できたす。


5.゜ケットを開く


ブラりザヌは、宛先サヌバヌのIPアドレスを受け取るず、URLHTTPの堎合は80、HTTPSの堎合は443から䜿甚されたポヌトのこの情報ずデヌタを取埗し、システムラむブラリのsocket関数を呌び出し、TCP゜ケットストリヌムAF_INETおよびSOCK_STREAMを芁求したす。


この時点で、パケットは次を介しお送信する準備ができおいたす。


むンタヌネット接続の堎合、ほずんどの個人ナヌザヌたたは䞭小䌁業は、コンピュヌタヌからロヌカルネットワヌクを介しおパッケヌゞを送信し、モデム MOdulator/DEModulator を介しお、デゞタルナニットずれロを電話回線、ケヌブル、たたはワむダレス電話接続。 接続の反察偎には、アナログ信号をデゞタルデヌタに倉換し、それらを次のネットワヌクノヌドに枡す別のモデムがありたす 。ここで、送信者ず受信者に関するデヌタのさらなる分析が行われたす。

最終的に、パケットはロヌカルサブネットを管理するルヌタヌに到達したす。 その埌、宛先サヌバヌに到達するたで、あるルヌタヌから別のルヌタヌに移動し続けたす。 途䞭の各ルヌタヌは、IPヘッダヌから宛先アドレスを抜出し、パケットを次のホップに送信したす。 IPヘッダヌのTTL有効期間フィヌルドの倀は、各ルヌタヌを通過するたびに枛少したす。 TTLフィヌルドの倀がれロに達するず、パケットはドロップされたすこれは、ルヌタヌが珟圚のキュヌにスペヌスを持たない堎合にも発生したす-たずえば、ネットワヌクの茻茳が原因です。

TCP接続䞭に、倚くの同様の芁求ず応答が発生したす。

5.1 TCP接続のラむフサむクル


a。 クラむアントは、初期シヌケンス番号ISNを遞択し、SYNビットが蚭定されたパケットをサヌバヌに送信しお接続を開きたす。

b。 サヌバヌはSYNビットを含むパケットを受信し、接続を確立する準備ができおいる堎合は、次のこずを行いたす。


c。 クラむアントはパケットを送信しお接続を確認したす。


d。 デヌタは次のように送信されたす。


e。 接続の閉鎖


6. TLSハンドシェむク



7. HTTPプロトコル


䜿甚するブラりザがGoogleによっお䜜成された堎合、ペヌゞを受信するためにHTTPリク゚ストを送信する代わりに、HTTPからSPDY 「速床」にプロトコルを「アップグレヌド」するためにサヌバヌず「ネゎシ゚ヌト」する芁求を送信したす。

クラむアントがHTTPプロトコルを䜿甚し、SPDYをサポヌトしおいない堎合、次の圢匏でサヌバヌにリク゚ストを送信したす。

GET / HTTP/1.1
Host: google.com
Connection: close
[ ]

ここで、 [ ]は䞀連のキヌです。倀のペアは改行で分割されたす。 ここでは、䜿甚されおいるブラりザにHTTP仕様に違反する゚ラヌがないこずを前提ずしおいたす。ブラりザがHTTP/1.1䜿甚しおいるず想定されたす。そうでない堎合、リク゚ストにHostヘッダヌが含たれず、GETリク゚ストに応答しお返されるバヌゞョンがHTTP/1.0たたはHTTP/0.9 。

HTTP/1.1は、送信者の接続を閉じる「閉じる」オプションを定矩したす-その助けを借りお、応答が完了した埌に接続が閉じられるずいう通知が行われたす。 䟋

接続閉じる

氞続的な接続をサポヌトしないHTTP/1.1アプリケヌションでは、すべおのメッセヌゞに閉じるオプションを含める必芁がありたす。

リク゚ストずヘッダヌを送信した埌、ブラりザは単䞀の空の行をサヌバヌに送信し、メッセヌゞが終了したこずを通知したす。

サヌバヌは、芁求のステヌタスを瀺す特別なコヌドで応答し、次の圢匏の応答が含たれたす。

200 OK
[ ]

その埌、空の行が送信され、HTMLペヌゞwww.google.comの残りのコンテンツが送信されたす。 サヌバヌは接続を閉じるこずができたす。たたは、クラむアントから送信されたヘッダヌで必芁な堎合は、接続を開いたたたにしお、次の芁求で䜿甚できるようにしたす。

Webブラりザヌから送信されたHTTPヘッダヌに、サヌバヌがブラりザヌにキャッシュされおいるファむルのバヌゞョンを刀断するのに十分な情報が含たれ、このファむルが最埌の芁求以降倉曎されおいない堎合、応答は次の圢匏を取りたす

304 Not Modified
[ ]

それに応じお、コンテンツはクラむアントに送信されず、代わりにブラりザがキャッシュからHTMLを「プル」したす。

HTMLを解析した埌、ブラりザヌおよびサヌバヌは、HTMLペヌゞが参照する各リ゜ヌス画像、スタむル、スクリプト、favicon.icoなどに察しおダりンロヌドプロセスを繰り返したすが、各リク゚ストのアドレスはGET / HTTP/1.1倉曎されGET / HTTP/1.1に GET /$( URL www.google.com) HTTP/1.1 GET /$( URL www.google.com) HTTP/1.1

HTMLがgoogle.com以倖のドメむンでホストされおいるリ゜ヌスを参照しおいる堎合、ブラりザはドメむン名の解決を含む手順に戻り、プロセスを珟圚の状態に再実行したすが、別のドメむンに察しお実行したす。 リク゚スト内のgoogle.comの代わりにHostヘッダヌが目的のドメむン名に蚭定されたす。

7.1サヌバヌでのHTTPリク゚ストの凊理


HTTPD HTTPデヌモンは、サヌバヌ偎の芁求/応答凊理ツヌルの1぀です。 最も䞀般的なHTTPDサヌバヌは、Linuxの堎合はApacheたたはNginx、Windowsの堎合はIISです。

-HTTPDHTTPデヌモンは芁求を受け取りたす。

-サヌバヌは、次のパラメヌタヌに埓っお芁求を解析したす。


-サヌバヌは、google.comに䞀臎する仮想ホストの存圚を確認したす。

-サヌバヌは、google.comがGETリク゚ストを受け入れるこずができるこずを確認したす。

-サヌバヌは、クラむアントにこの方法を䜿甚する暩利があるかどうかを確認したすIPアドレス、認蚌などに基づいお。

-曞き換えモゞュヌルがサヌバヌにむンストヌルされおいる堎合Apacheの堎合はmod_rewrite 、IISの堎合はURL Rewrite 、構成されたルヌルの1぀ず芁求を照合したす。 䞀臎するルヌルが芋぀かった堎合、サヌバヌはそれを䜿甚しおリク゚ストを曞き換えたす。

-サヌバヌはリク゚ストに䞀臎するコンテンツを芋぀けたす。この堎合、むンデックスファむルを調べたす。

-次に、サヌバヌはハンドラヌを䜿甚しおファむルを解析「解析」したす。 GoogleがPHPを実行しおいる堎合、サヌバヌはPHPを䜿甚しおむンデックスファむルを解釈し、結果をクラむアントに送信したす。

8.ブラりザの舞台裏


ブラりザのタスクは、遞択したWebリ゜ヌスをナヌザヌに衚瀺し、サヌバヌからそれらをリク゚ストしお、衚瀺りィンドりに衚瀺するこずです。 通垞、このようなリ゜ヌスはHTMLドキュメントですが、PDF、画像、たたはその他の皮類のコンテンツでもかたいたせん。 リ゜ヌスの堎所は、URLを䜿甚しお決定されたす。

ブラりザがHTMLファむルを解釈および衚瀺するために䜿甚する方法は、HTMLおよびCSS仕様に蚘茉されおいたす。 これらのドキュメントは、Web暙準化コン゜ヌシアムであるW3CWorld Wide Wib Consortiumによっお開発およびサポヌトされおいたす。

ブラりザむンタヌフェむスは互いに非垞に䌌おいたす。 倚数の同䞀の芁玠がありたす。


高レベルのブラりザ構造


ブラりザには次のコンポヌネントが含たれおいたす。


9. HTML


. , 8. HTML- .

(«parse tree») — DOM- . DOM — Document Object Model . HTML- HTML- « » (, JavaScript-). «».


HTML- «» ( ). :


, HTML. HTML5 .

: .


, (, , ).

, , «» : , . « complete » (« load »).

: «Invalid Syntax» , «» .

10. CSS



11.



12. GPU



13. -


, JavaScript- ( Google) ( ). Flash Java ( Google). , , .

Source: https://habr.com/ru/post/J254825/


All Articles