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

硬件層---鍵盤到CPU

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

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

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

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

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

內核層到應用層

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

整個流程是[]()

scanf ---> 系統調用read ---> 內核態阻塞等待 ---> 讀取拷貝數據 ---> 用戶態接收數據[]()

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

網絡請求

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

DNS解析

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

傳輸數據準備

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

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

建立連接

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

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

傳輸數據

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

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

由于http協議是無狀態的，所以本次傳輸完數據以后，這個鏈接就關閉了。[]()

完成顯示

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

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