前幾天看到一個題目，問在瀏覽器中輸入一個URL會發(fā)生神馬，這好像是網(wǎng)上比較流行的面試題，而且也被回答爛了，仔細想下來，要是自己遇到這個題目能不能答上來，后來一想， 這個題目要完全答出來可以把大學開始的幾乎所有知識都用上。 呵呵，為了模擬面試，所以都憑印象說的，沒有查網(wǎng)絡(luò)資料，所以估計很多地方都不對，歡迎來拍。[]()后續(xù)可以總結(jié)一個非常非常詳細的版本，個人感覺真的可以把大學開始的所有的東西都用上，包括連數(shù)電模電（全部流程都跑不掉），信息論（gzip壓縮），密碼學（HTTPS）,通訊原理（網(wǎng)絡(luò)基帶傳輸）這種都可以，本文還是以軟件處理過程為主。[]()

硬件層---鍵盤到CPU

[]()輸入網(wǎng)址嘛，那就是鍵盤輸入了，鍵盤一般用usb或者PS/2口連接電腦，現(xiàn)在見過PS/2口的人不多了吧，我們就看看usb吧，usb分為主從模式，一般的鍵盤本身的usb是一個從設(shè)備，相應(yīng)的還有u盤啊，鼠標啊都是從設(shè)備，對應(yīng)的主機端的USBcontroller是一個主設(shè)備，這個主設(shè)備掛在CPU上，在X86結(jié)構(gòu)的機器上是掛在主板的南橋（好像是的，反正是低速的那個）芯片上，如果是ARM這類嵌入式設(shè)備的話，那么就是掛在APB總線上，對這個我熟悉一些，就按ARM這種SoC來說吧，當是在手機上輸入URL吧，呵呵。[]()

鍵盤輸入字符以后，通過USB協(xié)議（USB協(xié)議簡單的來說就是一個串行協(xié)議，靠一個時鐘電信號和一個數(shù)據(jù)電信號傳輸數(shù)據(jù)）將數(shù)據(jù)傳輸?shù)紸PB總線上的USB控制器上。然后這個控制器開始搶總線，總線的APB橋接收到信號以后也開始通過APB總線上的時鐘和數(shù)據(jù)線發(fā)送一個中斷信號到APB橋中，APB橋同時連接在AHP高速總線上，接收完數(shù)據(jù)以后，它開始搶高速總線，高速總線上有個Arbiter(總線仲裁器)，因為高速總線上接的都是內(nèi)存啊這種家伙，你一個小小的USB不見得搶得過他們，等仲裁器給你時間以后，APB橋開始把中斷信號發(fā)給CPU。[]()

CPU接收到這個中斷以后，要是沒有其他更高級的中斷需要處理的話就會調(diào)用內(nèi)核中的中斷處理函數(shù)開始處理中斷，中斷處理函數(shù)又分為底半部和頂半部，首先會是底半部處理，把中斷放到處理隊列中就返回了，然后頂半部從隊列根據(jù)注冊的的中斷號拿到自己對應(yīng)的中斷號進行處理，這時候中斷處理函數(shù)就算收到這個信號了，相當于硬件的電信號已經(jīng)傳遞到軟件層了，中斷處理函數(shù)會調(diào)用USB的驅(qū)動程序去USB控制器上讀取這個輸入的字符，這個字符還是通過兩條總線（APB和AHB）以獨占的方式傳遞到軟件層上，其實呢，是軟件控制這個信號寫到了內(nèi)存的某個空間上。[]()

整個流程是這樣的[]()

發(fā)出中斷 ：鍵盤--->usb控制器 ---> APB橋 ---> CPU硬件中斷 ---> 中斷處理底部 ---> 中斷處理函數(shù)頂部 ---> 驅(qū)動程序 ---> 讀取數(shù)據(jù) ---> CPU尋址 ---> 寫入內(nèi)存[]()

內(nèi)核層到應(yīng)用層

[]()假設(shè)我們輸入的url以C語言的scanf函數(shù)為例，scanf函數(shù)會一直在內(nèi)核態(tài)阻塞著，直到中斷處理函數(shù)接收到了所有的字符并且接受到了一個回車符，這時scanf語句會通過操作系統(tǒng)的read調(diào)用把緩沖區(qū)的所有字符從內(nèi)核態(tài)拷貝到用戶態(tài)，這時這些個字符就從電信號傳遞到了應(yīng)用程序（瀏覽器）的軟件層了。[]()

整個流程是[]()

scanf ---> 系統(tǒng)調(diào)用read ---> 內(nèi)核態(tài)阻塞等待 ---> 讀取拷貝數(shù)據(jù) ---> 用戶態(tài)接收數(shù)據(jù)[]()

因為軟件層也不是一個實體層次，其實所有的操作最后都變成了硬件的電信號，所有沒辦法把流程寫得很明白，大概就是這么個意思吧。[]()

網(wǎng)絡(luò)請求

[]()應(yīng)用程序（瀏覽器）接收到這個URL以后，就開始走網(wǎng)絡(luò)層來獲取數(shù)據(jù)了，這里我們就不深入到底層的電信號了，就按網(wǎng)絡(luò)這一套來說吧。[]()

DNS解析

[]()首先就要解析域名了，瀏覽器會先看一下本地的host文件，看有沒有url域名對應(yīng)的ip地址，如果沒有的話，會通過DNS協(xié)議發(fā)送數(shù)據(jù)包給DNS服務(wù)器詢問域名的ip地址，DNS服務(wù)自己沒有對應(yīng)的ip的話會繼續(xù)往上尋找，然后把ip地址發(fā)回給瀏覽器。DNS協(xié)議是UDP的，但好像有特殊情況是TCP連接，好像是各個DNS服務(wù)器之間傳輸用的TCP吧，不管了，反正通過UDP這個傳輸層協(xié)議之上的DNS應(yīng)用層協(xié)議把url對應(yīng)的ip地址得到了。[]()

傳輸數(shù)據(jù)準備

[]()拿到ip地址以后，假設(shè)我們輸入的網(wǎng)址是https://www.baidu.com/，百度的服務(wù)器在北京，而我們在上海，瀏覽器就通過connect開始連接這個這個北京的ip地址了，連接跑到tcp/ip協(xié)議棧以后，協(xié)議棧一看這個IP和本地IP根本就不在一個段上啊，那ARP也不發(fā)了，直接把數(shù)據(jù)包轉(zhuǎn)發(fā)到網(wǎng)關(guān)上，也就是家里的路由器上了，路由器拿到地址，查一下本地的路由表，呀，我這小路由表上沒這個網(wǎng)段的啊，那我不管了，給我的上級路由吧（也許是小區(qū)的大路由器了），小區(qū)路由一看，我這也沒有啊，這樣一級一級傳遞到了上海的城際路由上，然后到了北京的城際路由，這么一層一層下來終于傳到了百度的服務(wù)器上。[]()

在這里看上去簡單，但是路由的算法是很復(fù)雜的，這一塊我也不太懂沒弄過，但是Dijkstra選路算法還是明白的，別問我為什么記得這個單詞，大學計算機網(wǎng)絡(luò)課的課程作業(yè)啊，就是實現(xiàn)這個Dijkstra啊，通過路由算法，終于把第一個數(shù)據(jù)包發(fā)送給百度的服務(wù)器了。[]()

建立連接

[]()這個數(shù)據(jù)包是神馬呢，就是我們熟悉的TCP三次握手的第一握了，SYN=1的那個數(shù)據(jù)包，關(guān)于三次握手就不多說了，大家都知道，關(guān)鍵是我不記得細節(jié)了，反正就是大家都懂的，握手完了連接就建立完了。為什么建立連接需要三次握手，關(guān)閉連接需要四次握手，呵呵，寫不動了。[]()

同時，在百度服務(wù)器這邊，有個web服務(wù)器的應(yīng)用程序（比如Nginx），一直在監(jiān)聽著80端口，收到這個數(shù)據(jù)包以后也同時和客戶端建立起了連接了。[]()

傳輸數(shù)據(jù)

[]()連接建立好以后，是TCP連接建立了，這時通過更上層的HTTP協(xié)議開始傳輸數(shù)據(jù)，HTTP協(xié)議本身很復(fù)雜，這里我們簡單的來說，就是瀏覽器發(fā)送了一個GET / HTTP/1.1 \\n\\r字符串給了服務(wù)器，服務(wù)器接受到這個字符串以后，通過協(xié)議棧傳遞給了上層的Nginx應(yīng)用程序。[]()

應(yīng)用程序一看這個地址是/，然后對照一下自己的配置文件nginx.conf，有個配置告訴他碰到這種請求，直接把本地的index.html吐出去，于是Nginx讀取index.html并把數(shù)據(jù)通過這條TCP連接回復(fù)給了客戶端。[]()

由于http協(xié)議是無狀態(tài)的，所以本次傳輸完數(shù)據(jù)以后，這個鏈接就關(guān)閉了。[]()

完成顯示

[]()好了，后面的就是接受到數(shù)據(jù)的顯示了，關(guān)于webkit內(nèi)核的細節(jié)就真不清楚了，就是解DOM樹，執(zhí)行JS代碼，重新請求CSS和圖片，然后把頁面畫出來吧。[]()

哦了，題目做完了，其實還有很多細節(jié)沒有說的，比如網(wǎng)絡(luò)尋址的時候的ARP協(xié)議啊，路由器尋路的其他很多算法啊，Nginx處理請求的時候的幾個階段解讀啊，是否需要反向代理到后端的服務(wù)器上啊，最后顯示的時候還需要操作顯卡進行顯存的操作，如果頁面中有復(fù)雜的圖形效果還需要GPU參與運算之類的，要寫就寫不完了。