一個(gè)完整的HTTP請(qǐng)求過程
域名解析 —> 與服務(wù)器建立連接 —> 發(fā)起HTTP請(qǐng)求 —> 服務(wù)器響應(yīng)HTTP請(qǐng)求，瀏覽器得到html代碼 —> 瀏覽器解析html代碼，并請(qǐng)求html代碼中的資源（如js捷犹、css资盅、圖片） —> 瀏覽器對(duì)頁面進(jìn)行渲染呈現(xiàn)給用戶
以Chrome瀏覽器為例：
① Chrome瀏覽器 會(huì)首先搜索瀏覽器自身的DNS緩存（緩存時(shí)間比較短蚁署，大概只有1分鐘纤子，且只能容納1000條緩存）胞此，看自身的緩存中是否有https://www.cnblogs.com?對(duì)應(yīng)的條目恶迈，而且沒有過期涩金，如果有且沒有過期則解析到此結(jié)束。
注：我們?cè)趺床榭碈hrome自身的緩存蝉绷？可以使用 chrome://net-internals/#dns 來進(jìn)行查看
② 如果瀏覽器自身的緩存里面沒有找到對(duì)應(yīng)的條目鸭廷，那么Chrome會(huì)搜索操作系統(tǒng)自身的DNS緩存,如果找到且沒有過期則停止搜索解析到此結(jié)束.
注：怎么查看操作系統(tǒng)自身的DNS緩存，以Windows系統(tǒng)為例熔吗，可以在命令行下使用 ipconfig /displaydns 來進(jìn)行查看
③ 如果在Windows系統(tǒng)的DNS緩存也沒有找到辆床，那么嘗試讀取hosts文件（位于C:\Windows\System32\drivers\etc），看看這里面有沒有該域名對(duì)應(yīng)的IP地址桅狠，如果有則解析成功讼载。
④ 如果在hosts文件中也沒有找到對(duì)應(yīng)的條目轿秧，瀏覽器就會(huì)發(fā)起一個(gè)DNS的系統(tǒng)調(diào)用，就會(huì)向本地配置的首選DNS服務(wù)器（一般是電信運(yùn)營(yíng)商提供的咨堤，也可以使用像Google提供的DNS服務(wù)器）發(fā)起域名解析請(qǐng)求（通過的是UDP協(xié)議向DNS的53端口發(fā)起請(qǐng)求菇篡，這個(gè)請(qǐng)求是遞歸的請(qǐng)求，也就是運(yùn)營(yíng)商的DNS服務(wù)器必須得提供給我們?cè)撚蛎腎P地址）一喘，運(yùn)營(yíng)商的DNS服務(wù)器首先查找自身的緩存驱还，找到對(duì)應(yīng)的條目，且沒有過期凸克，則解析成功议蟆。如果沒有找到對(duì)應(yīng)的條目，則有運(yùn)營(yíng)商的DNS代我們的瀏覽器發(fā)起迭代DNS解析請(qǐng)求萎战，它首先是會(huì)找根域的DNS的IP地址（這個(gè)DNS服務(wù)器都內(nèi)置13臺(tái)根域的DNS的IP地址）咐容，找打根域的DNS地址，就會(huì)向其發(fā)起請(qǐng)求（請(qǐng)問www.cnblogs.com這個(gè)域名的IP地址是多少奥煳戳粒？），根域發(fā)現(xiàn)這是一個(gè)頂級(jí)域com域的一個(gè)域名虫啥，于是就告訴運(yùn)營(yíng)商的DNS我不知道這個(gè)域名的IP地址蔚约，但是我知道com域的IP地址，你去找它去孝鹊，于是運(yùn)營(yíng)商的DNS就得到了com域的IP地址炊琉，又向com域的IP地址發(fā)起了請(qǐng)求（請(qǐng)問www.cnblogs.com這個(gè)域名的IP地址是多少?）,com域這臺(tái)服務(wù)器告訴運(yùn)營(yíng)商的DNS我不知道www.cnblogs.com這個(gè)域名的IP地址，但是我知道cnblogs.com這個(gè)域的DNS地址又活，你去找它去苔咪，于是運(yùn)營(yíng)商的DNS又向cnblogs.com這個(gè)域名的DNS地址（這個(gè)一般就是由域名注冊(cè)商提供的，像萬網(wǎng)柳骄，新網(wǎng)等）發(fā)起請(qǐng)求（請(qǐng)問www.cnblogs.com這個(gè)域名的IP地址是多少团赏？），這個(gè)時(shí)候cnblogs.com域的DNS服務(wù)器一查耐薯，誒舔清，果真在我這里，于是就把找到的結(jié)果發(fā)送給運(yùn)營(yíng)商的DNS服務(wù)器曲初，這個(gè)時(shí)候運(yùn)營(yíng)商的DNS服務(wù)器就拿到了www.cnblogs.com這個(gè)域名對(duì)應(yīng)的IP地址体谒，并返回給Windows系統(tǒng)內(nèi)核，內(nèi)核又把結(jié)果返回給瀏覽器臼婆，終于瀏覽器拿到了www.cnblogs.com 對(duì)應(yīng)的IP地址抒痒，該進(jìn)行一步的動(dòng)作了。
注：一般情況下是不會(huì)進(jìn)行以下步驟的
如果經(jīng)過以上的4個(gè)步驟颁褂，還沒有解析成功故响，那么會(huì)進(jìn)行如下步驟（以下是針對(duì)Windows操作系統(tǒng)）：
⑤ 操作系統(tǒng)就會(huì)查找NetBIOS name Cache（NetBIOS名稱緩存傀广，就存在客戶端電腦中的），那這個(gè)緩存有什么東西呢彩届？凡是最近一段時(shí)間內(nèi)和我成功通訊的計(jì)算機(jī)的計(jì)算機(jī)名和Ip地址伪冰，就都會(huì)存在這個(gè)緩存里面。什么情況下該步能解析成功呢樟蠕？就是該名稱正好是幾分鐘前和我成功通信過贮聂，那么這一步就可以成功解析。
⑥ 如果第⑤步也沒有成功寨辩，那會(huì)查詢WINS 服務(wù)器（是NETBIOS名稱和IP地址對(duì)應(yīng)的服務(wù)器）
⑦ 如果第⑥步也沒有查詢成功寂汇，那么客戶端就要進(jìn)行廣播查找
⑧ 如果第⑦步也沒有成功，那么客戶端就讀取LMHOSTS文件（和HOSTS文件同一個(gè)目錄下捣染，寫法也一樣）
如果第八步還沒有解析成功，那么就宣告這次解析失敗停巷，那就無法跟目標(biāo)計(jì)算機(jī)進(jìn)行通信耍攘。只要這八步中有一步可以解析成功，那就可以成功和目標(biāo)計(jì)算機(jī)進(jìn)行通信畔勤。
2.1 TCP連接的建立
客戶端的請(qǐng)求到達(dá)服務(wù)器蕾各，首先就是建立TCP連接
來源于：https://blog.csdn.net/u012248450/article/details/51036329
Client首先發(fā)送一個(gè)連接試探，ACK=0 表示確認(rèn)號(hào)無效庆揪，SYN = 1 表示這是一個(gè)連接請(qǐng)求或連接接受報(bào)文式曲，同時(shí)表示這個(gè)數(shù)據(jù)報(bào)不能攜帶數(shù)據(jù)，seq = x 表示Client自己的初始序號(hào)（seq = 0 就代表這是第0號(hào)包）缸榛，這時(shí)候Client進(jìn)入syn_sent狀態(tài)吝羞，表示客戶端等待服務(wù)器的回復(fù)
Server監(jiān)聽到連接請(qǐng)求報(bào)文后，如同意建立連接内颗，則向Client發(fā)送確認(rèn)钧排。TCP報(bào)文首部中的SYN 和 ACK都置1 ，ack = x + 1表示期望收到對(duì)方下一個(gè)報(bào)文段的第一個(gè)數(shù)據(jù)字節(jié)序號(hào)是x+1均澳，同時(shí)表明x為止的所有數(shù)據(jù)都已正確收到（ack=1其實(shí)是ack=0+1,也就是期望客戶端的第1個(gè)包）恨溜，seq = y 表示Server 自己的初始序號(hào)（seq=0就代表這是服務(wù)器這邊發(fā)出的第0號(hào)包）。這時(shí)服務(wù)器進(jìn)入syn_rcvd找前，表示服務(wù)器已經(jīng)收到Client的連接請(qǐng)求糟袁，等待client的確認(rèn)。
Client收到確認(rèn)后還需再次發(fā)送確認(rèn)躺盛，同時(shí)攜帶要發(fā)送給Server的數(shù)據(jù)项戴。ACK 置1 表示確認(rèn)號(hào)ack= y + 1 有效（代表期望收到服務(wù)器的第1個(gè)包），Client自己的序號(hào)seq= x + 1（表示這就是我的第1個(gè)包颗品，相對(duì)于第0個(gè)包來說的）肯尺，一旦收到Client的確認(rèn)之后沃缘，這個(gè)TCP連接就進(jìn)入Established狀態(tài)，就可以發(fā)起http請(qǐng)求了则吟。
問題1：TCP 為什么需要3次握手槐臀？
2個(gè)計(jì)算機(jī)通信是靠協(xié)議（目前流行的TCP/IP協(xié)議）來實(shí)現(xiàn),如果2個(gè)計(jì)算機(jī)使用的協(xié)議不一樣，那是不能進(jìn)行通信的氓仲，所以這個(gè)3次握手就相當(dāng)于試探一下對(duì)方是否遵循TCP/IP協(xié)議水慨，協(xié)商完成后就可以進(jìn)行通信了，當(dāng)然這樣理解不是那么準(zhǔn)確敬扛。
問題2：為什么HTTP協(xié)議要基于TCP來實(shí)現(xiàn)晰洒？
目前在Internet中所有的傳輸都是通過TCP/IP進(jìn)行的，HTTP協(xié)議作為TCP/IP模型中應(yīng)用層的協(xié)議也不例外啥箭，TCP是一個(gè)端到端的可靠的面向連接的協(xié)議谍珊，所以HTTP基于傳輸層TCP協(xié)議不用擔(dān)心數(shù)據(jù)的傳輸?shù)母鞣N問題。
2.2 常見TCP連接限制
2.2.1 修改用戶進(jìn)程可打開文件數(shù)限制
在Linux平臺(tái)上急侥，無論編寫客戶端程序還是服務(wù)端程序砌滞，在進(jìn)行高并發(fā)TCP連接處理時(shí)，最高的并發(fā)數(shù)量都要受到系統(tǒng)對(duì)用戶單一進(jìn)程同時(shí)可打開文件數(shù)量的限制(這是因?yàn)橄到y(tǒng)為每個(gè)TCP連接都要?jiǎng)?chuàng)建一個(gè)socket句柄坏怪，每個(gè)socket句柄同時(shí)也是一個(gè)文件句柄)贝润。可使用ulimit命令查看系統(tǒng)允許當(dāng)前用戶進(jìn)程打開的文件數(shù)限制铝宵，windows上是256打掘，linux是1024，這個(gè)博客的服務(wù)器是65535
2.2.2 修改網(wǎng)絡(luò)內(nèi)核對(duì)TCP連接的有關(guān)限制
在Linux上編寫支持高并發(fā)TCP連接的客戶端通訊處理程序時(shí)鹏秋，有時(shí)會(huì)發(fā)現(xiàn)盡管已經(jīng)解除了系統(tǒng)對(duì)用戶同時(shí)打開文件數(shù)的限制尊蚁，但仍會(huì)出現(xiàn)并發(fā)TCP連接數(shù)增加到一定數(shù)量時(shí)，再也無法成功建立新的TCP連接的現(xiàn)象侣夷。出現(xiàn)這種現(xiàn)在的原因有多種枝誊。?
第一種原因可能是因?yàn)長(zhǎng)inux網(wǎng)絡(luò)內(nèi)核對(duì)本地端口號(hào)范圍有限制。此時(shí)惜纸，進(jìn)一步分析為什么無法建立TCP連接叶撒，會(huì)發(fā)現(xiàn)問題出在connect()調(diào)用返回失敗，查看系統(tǒng)錯(cuò)誤提示消息是“Can’t assign requestedaddress”耐版。同時(shí)祠够，如果在此時(shí)用tcpdump工具監(jiān)視網(wǎng)絡(luò)，會(huì)發(fā)現(xiàn)根本沒有TCP連接時(shí)客戶端發(fā)SYN包的網(wǎng)絡(luò)流量粪牲。這些情況說明問題在于本地Linux系統(tǒng)內(nèi)核中有限制古瓤。
其實(shí)，問題的根本原因在于Linux內(nèi)核的TCP/IP協(xié)議實(shí)現(xiàn)模塊對(duì)系統(tǒng)中所有的客戶端TCP連接對(duì)應(yīng)的本地端口號(hào)的范圍進(jìn)行了限制(例如，內(nèi)核限制本地端口號(hào)的范圍為1024~32768之間)落君。當(dāng)系統(tǒng)中某一時(shí)刻同時(shí)存在太多的TCP客戶端連接時(shí)穿香，由于每個(gè)TCP客戶端連接都要占用一個(gè)唯一的本地端口號(hào)(此端口號(hào)在系統(tǒng)的本地端口號(hào)范圍限制中)，如果現(xiàn)有的TCP客戶端連接已將所有的本地端口號(hào)占滿绎速，則此時(shí)就無法為新的TCP客戶端連接分配一個(gè)本地端口號(hào)了皮获，因此系統(tǒng)會(huì)在這種情況下在connect()調(diào)用中返回失敗，并將錯(cuò)誤提示消息設(shè)為“Can’t assignrequested address”纹冤。
2.3 TCP四次揮手
當(dāng)客戶端和服務(wù)器通過三次握手建立了TCP連接以后洒宝，當(dāng)數(shù)據(jù)傳送完畢，肯定是要斷開TCP連接的啊萌京。那對(duì)于TCP的斷開連接雁歌，這里就有了神秘的“四次分手”。
來源于：https://blog.csdn.net/LRH0211/article/details/72724361
第一次分手：主機(jī)1（可以使客戶端知残，也可以是服務(wù)器端）靠瞎，設(shè)置Sequence Number，向主機(jī)2發(fā)送一個(gè)FIN報(bào)文段求妹；此時(shí)较坛，主機(jī)1進(jìn)入FIN_WAIT_1狀態(tài)；這表示主機(jī)1沒有數(shù)據(jù)要發(fā)送給主機(jī)2了扒最；
第二次分手：主機(jī)2收到了主機(jī)1發(fā)送的FIN報(bào)文段，向主機(jī)1回一個(gè)ACK報(bào)文段华嘹，Acknowledgment Number為Sequence Number加1吧趣；主機(jī)1進(jìn)入FIN_WAIT_2狀態(tài)；主機(jī)2告訴主機(jī)1耙厚，我“同意”你的關(guān)閉請(qǐng)求强挫；
第三次分手：主機(jī)2向主機(jī)1發(fā)送FIN報(bào)文段，請(qǐng)求關(guān)閉連接薛躬，同時(shí)主機(jī)2進(jìn)入LAST_ACK狀態(tài)俯渤；
第四次分手：主機(jī)1收到主機(jī)2發(fā)送的FIN報(bào)文段，向主機(jī)2發(fā)送ACK報(bào)文段型宝，然后主機(jī)1進(jìn)入TIME_WAIT狀態(tài)八匠；主機(jī)2收到主機(jī)1的ACK報(bào)文段以后，就關(guān)閉連接趴酣；此時(shí)梨树，主機(jī)1等待2MSL后依然沒有收到回復(fù)，則證明Server端已正常關(guān)閉岖寞，那好抡四，主機(jī)1也可以關(guān)閉連接了。
問題1：為什么要四次分手？
TCP協(xié)議是一種面向連接的指巡、可靠的淑履、基于字節(jié)流的運(yùn)輸層通信協(xié)議。TCP是全雙工模式藻雪，這就意味著秘噪，當(dāng)主機(jī)1發(fā)出FIN報(bào)文段時(shí)，只是表示主機(jī)1已經(jīng)沒有數(shù)據(jù)要發(fā)送了阔涉，主機(jī)1告訴主機(jī)2缆娃，它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢了；但是瑰排，這個(gè)時(shí)候主機(jī)1還是可以接受來自主機(jī)2的數(shù)據(jù)贯要；當(dāng)主機(jī)2返回ACK報(bào)文段時(shí)，表示它已經(jīng)知道主機(jī)1沒有數(shù)據(jù)發(fā)送了椭住，但是主機(jī)2還是可以發(fā)送數(shù)據(jù)到主機(jī)1的崇渗；當(dāng)主機(jī)2也發(fā)送了FIN報(bào)文段時(shí)，這個(gè)時(shí)候就表示主機(jī)2也沒有數(shù)據(jù)要發(fā)送了京郑，就會(huì)告訴主機(jī)1宅广，我也沒有數(shù)據(jù)要發(fā)送了，之后彼此就會(huì)愉快的中斷這次TCP連接些举。
3.1 HTTP協(xié)議
HTTP是一個(gè)客戶端和服務(wù)器端請(qǐng)求和應(yīng)答的標(biāo)準(zhǔn)（TCP）跟狱。客戶端是終端用戶户魏，服務(wù)器端是網(wǎng)站驶臊。通過使用Web瀏覽器、網(wǎng)絡(luò)爬蟲或者其它的工具叼丑，客戶端發(fā)起一個(gè)到服務(wù)器上指定端口（默認(rèn)端口為80）的HTTP請(qǐng)求关翎。
通俗來講，他就是計(jì)算機(jī)通過網(wǎng)絡(luò)進(jìn)行通信的規(guī)則鸠信，是一個(gè)基于請(qǐng)求與響應(yīng)纵寝，無狀態(tài)的，應(yīng)用層的協(xié)議星立，乘睿基于TCP/IP協(xié)議傳輸數(shù)據(jù)。目前任何終端（手機(jī)绰垂，筆記本電腦闹啦。。）之間進(jìn)行任何一種通信都必須按照Http協(xié)議進(jìn)行辕坝，否則無法連接窍奋。
3.1.1 四個(gè)基于
請(qǐng)求與響應(yīng)：客戶端發(fā)送請(qǐng)求，服務(wù)器端響應(yīng)數(shù)據(jù)
無狀態(tài)的：協(xié)議對(duì)于事務(wù)處理沒有記憶能力，客戶端第一次與服務(wù)器建立連接發(fā)送請(qǐng)求時(shí)需要進(jìn)行一系列的安全認(rèn)證匹配等琳袄，因此增加頁面等待時(shí)間江场，當(dāng)客戶端向服務(wù)器端發(fā)送請(qǐng)求，服務(wù)器端響應(yīng)完畢后窖逗，兩者斷開連接址否，也不保存連接狀態(tài)，一刀兩斷碎紊！恩斷義絕佑附！從此路人！下一次客戶端向同樣的服務(wù)器發(fā)送請(qǐng)求時(shí)仗考，由于他們之前已經(jīng)遺忘了彼此音同，所以需要重新建立連接。
應(yīng)用層：?Http是屬于應(yīng)用層的協(xié)議秃嗜，配合TCP/IP使用权均。
TCP/IP：?Http使用TCP作為它的支撐運(yùn)輸協(xié)議。HTTP客戶機(jī)發(fā)起一個(gè)與服務(wù)器的TCP連接锅锨，一旦連接建立叽赊，瀏覽器（客戶機(jī)）和服務(wù)器進(jìn)程就可以通過套接字接口訪問TCP。
3.2 HTTP請(qǐng)求報(bào)文
一個(gè)HTTP請(qǐng)求報(bào)文由請(qǐng)求行（request line）必搞、請(qǐng)求頭部（header）必指、空行和請(qǐng)求數(shù)據(jù)4個(gè)部分組成，下圖給出了請(qǐng)求報(bào)文的一般格式恕洲。
來源于：https://blog.csdn.net/LRH0211/article/details/72724361
3.2.1 請(qǐng)求行
請(qǐng)求行分為三個(gè)部分：請(qǐng)求方法塔橡、請(qǐng)求地址和協(xié)議版本
請(qǐng)求方法
HTTP/1.1 定義的請(qǐng)求方法有8種：GET、POST研侣、PUT、DELETE炮捧、PATCH庶诡、HEAD、OPTIONS咆课、TRACE末誓。
最常的兩種GET和POST，如果是RESTful接口的話一般會(huì)用到GET书蚪、POST喇澡、DELETE、PUT殊校。
請(qǐng)求地址
URL:統(tǒng)一資源定位符晴玖，是一種自愿位置的抽象唯一識(shí)別方法。
組成：<協(xié)議>：//<主機(jī)>：<端口>/<路徑>?注：端口和路徑有時(shí)可以省略（HTTP默認(rèn)端口號(hào)是80）
https://localhost:8080/index.html?key1=value1&keys2=value2
協(xié)議版本
協(xié)議版本的格式為：HTTP/主版本號(hào).次版本號(hào)，常用的有HTTP/1.0和HTTP/1.1
3.2.2 請(qǐng)求頭部
請(qǐng)求頭部為請(qǐng)求報(bào)文添加了一些附加信息呕屎，由“名/值”對(duì)組成让簿，每行一對(duì)，名和值之間使用冒號(hào)分隔秀睛。
常見請(qǐng)求頭如下：
來源于：https://blog.csdn.net/LRH0211/article/details/72724361
請(qǐng)求頭部的最后會(huì)有一個(gè)空行尔当，表示請(qǐng)求頭部結(jié)束，接下來為請(qǐng)求數(shù)據(jù)蹂安，這一行非常重要椭迎，必不可少。
3.2.3 請(qǐng)求數(shù)據(jù)
可選部分田盈，比如GET請(qǐng)求就沒有請(qǐng)求數(shù)據(jù)畜号。
下面是一個(gè)POST方法的請(qǐng)求報(bào)文：
POST /index.php HTTP/1.1 請(qǐng)求行
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 請(qǐng)求頭
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: zh-cn,zh;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://localhost/
Content-Length：25
Content-Type：application/x-www-form-urlencoded
空行
username=aa&password=1234 請(qǐng)求數(shù)據(jù)
1
2
3
4
5
6
7
8
9
10
11
12
13
4. 服務(wù)器響應(yīng)HTTP請(qǐng)求，瀏覽器得到html代碼
4.1 負(fù)載均衡
接收到HTTP請(qǐng)求之后缠黍，就輪到負(fù)載均衡登場(chǎng)了弄兜，它位于網(wǎng)站的最前端，把短時(shí)間內(nèi)較高的訪問量分?jǐn)偟讲煌瑱C(jī)器上處理瓷式。負(fù)載均衡方案有軟件替饿、硬件兩種
4.1.1 負(fù)載均衡硬件方案
F5 BIG-IP是著名的硬件方案，但這里不作討論
4.1.2 負(fù)載均衡軟件方案
有LVS HAProxy Nginx等贸典，留作以后補(bǔ)充
在典型的Rails應(yīng)用部署方案中视卢，Nginx的作用有兩個(gè)
處理靜態(tài)文件請(qǐng)求
轉(zhuǎn)發(fā)請(qǐng)求給后端的Rails應(yīng)用?
這是一個(gè)簡(jiǎn)單的Nginx配置文件
來源于：https://blog.csdn.net/u012248450/article/details/51036329
后端的Rails服務(wù)器通過unix socket與Nginx通信，Nginx伺服public文件夾里的靜態(tài)文件給用戶
待完善…
4.2 Rails(應(yīng)用服務(wù)器)
4.3 數(shù)據(jù)庫(kù)（數(shù)據(jù)庫(kù)服務(wù)器）
4.4 Redis廊驼、Memercache（緩存服務(wù)器）
4.5 消息隊(duì)列
4.6 搜索
4.7 HTTP響應(yīng)報(bào)文
來源于：https://blog.csdn.net/LRH0211/article/details/72724361
HTTP響應(yīng)報(bào)文主要由狀態(tài)行据过、響應(yīng)頭部、空行以及響應(yīng)數(shù)據(jù)組成妒挎。
4.7.1 狀態(tài)行
由3部分組成绳锅，分別為：協(xié)議版本，狀態(tài)碼酝掩，狀態(tài)碼描述鳞芙。
其中協(xié)議版本與請(qǐng)求報(bào)文一致，狀態(tài)碼描述是對(duì)狀態(tài)碼的簡(jiǎn)單描述期虾，所以這里就只介紹狀態(tài)碼原朝。
狀態(tài)碼
狀態(tài)代碼為3位數(shù)字。
1xx：指示信息–表示請(qǐng)求已接收镶苞，繼續(xù)處理喳坠。
2xx：成功–表示請(qǐng)求已被成功接收、理解茂蚓、接受壕鹉。
3xx：重定向–要完成請(qǐng)求必須進(jìn)行更進(jìn)一步的操作剃幌。
4xx：客戶端錯(cuò)誤–請(qǐng)求有語法錯(cuò)誤或請(qǐng)求無法實(shí)現(xiàn)。
5xx：服務(wù)器端錯(cuò)誤–服務(wù)器未能實(shí)現(xiàn)合法的請(qǐng)求御板。
下面列舉幾個(gè)常見的：
來源于：https://blog.csdn.net/LRH0211/article/details/72724361
4.7.2 響應(yīng)頭部
與請(qǐng)求頭部類似锥忿，為響應(yīng)報(bào)文添加了一些附加信息
常見響應(yīng)頭部如下：
來源于：https://blog.csdn.net/LRH0211/article/details/72724361
4.7.3 響應(yīng)數(shù)據(jù)
用于存放需要返回給客戶端的數(shù)據(jù)信息。
下面是一個(gè)響應(yīng)報(bào)文的實(shí)例：
HTTP/1.1 200 OK 狀態(tài)行
Date: Sun, 17 Mar 2013 08:12:54 GMT 響應(yīng)頭部
Server: Apache/2.2.8 (Win32) PHP/5.2.5
X-Powered-By: PHP/5.2.5
Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 4393
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
空行
響應(yīng)數(shù)據(jù)
HTTP響應(yīng)示例
Hello HTTP!
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
關(guān)于請(qǐng)求頭部和響應(yīng)頭部的知識(shí)點(diǎn)很多怠肋，這里只是簡(jiǎn)單介紹敬鬓。
5. 瀏覽器解析html代碼，并請(qǐng)求html代碼中的資源
瀏覽器拿到index.html文件后笙各，就開始解析其中的html代碼钉答，遇到j(luò)s/css/image等靜態(tài)資源時(shí)，就向服務(wù)器端去請(qǐng)求下載（會(huì)使用多線程下載杈抢，每個(gè)瀏覽器的線程數(shù)不一樣）数尿，這個(gè)時(shí)候就用上keep-alive特性了，建立一次HTTP連接惶楼，可以請(qǐng)求多個(gè)資源右蹦，下載資源的順序就是按照代碼里的順序，但是由于每個(gè)資源大小不一樣歼捐，而瀏覽器又多線程請(qǐng)求請(qǐng)求資源何陆，所以從下圖看出，這里顯示的順序并不一定是代碼里面的順序豹储。
瀏覽器在請(qǐng)求靜態(tài)資源時(shí)（在未過期的情況下）贷盲，向服務(wù)器端發(fā)起一個(gè)http請(qǐng)求（詢問自從上一次修改時(shí)間到現(xiàn)在有沒有對(duì)資源進(jìn)行修改），如果服務(wù)器端返回304狀態(tài)碼（告訴瀏覽器服務(wù)器端沒有修改）剥扣，那么瀏覽器會(huì)直接讀取本地的該資源的緩存文件巩剖。
詳細(xì)的瀏覽器工作原理請(qǐng)看：http://kb.cnblogs.com/page/129756/
6. 瀏覽器對(duì)頁面進(jìn)行渲染呈現(xiàn)給用戶
最后，瀏覽器利用自己內(nèi)部的工作機(jī)制钠怯，把請(qǐng)求到的靜態(tài)資源和html代碼進(jìn)行渲染佳魔，渲染之后呈現(xiàn)給用戶。
一次完整的HTTP請(qǐng)求與響應(yīng)涉及了哪些知識(shí)晦炊？?https://blog.csdn.net/LRH0211/article/details/72724361
一次完整的HTTP請(qǐng)求過程?https://www.cnblogs.com/engeng/articles/5959335.html
后端知識(shí)體系–一次完整的HTTP請(qǐng)求?https://blog.csdn.net/u012248450/article/details/51036329
