- TCP/IP
- HTTP
- 瀏覽器打開一個網(wǎng)頁的過程
- 從（瀏覽器緩存元践、操作系統(tǒng)緩存片酝、硬盤host文件）查找DNS京腥；
- 解析DNS浪讳，獲得目標(biāo)IP篓吁；
- 根據(jù)IP莉擒，建立TCP連接（三次握手）挠唆；
- 瀏覽器向服務(wù)器發(fā)起HTTP請求婚脱；
- 服務(wù)器處理HTTP請求（響應(yīng)）粹懒；
- （如果沒有后續(xù)請求）斷開TCP連接（四次揮手）重付。
TCP/IP
1. TCP與UDP的區(qū)別
- TCP需要建立連接；
UDP不需要凫乖。 - TCP開銷大确垫，速度慢，傳輸可靠帽芽；
UDP開銷小删掀，速度快，傳輸不可靠导街。 - TPC面向數(shù)據(jù)流披泪；
UDP面向數(shù)據(jù)報。
2. TCP連接的建立與斷開
建立連接：三次握手菊匿；
斷開連接：四次揮手付呕。
3. 三次握手的過程（通俗版）
- 主機A通過向主機B 發(fā)送一個含有同步序列號的標(biāo)志位的數(shù)據(jù)段給主機B ，向主機B 請求建立連接跌捆，通過這個數(shù)據(jù)段徽职，主機A告訴主機B 兩件事：
我想要和你通信；你可以用哪個序列號作為起始數(shù)據(jù)段來回應(yīng)我佩厚。- 主機B 收到主機A的請求后姆钉，用一個帶有確認應(yīng)答(ACK)和同步序列號(SYN)標(biāo)志位的數(shù)據(jù)段響應(yīng)主機A，也告訴主機A兩件事：
我已經(jīng)收到你的請求了抄瓦，你可以傳輸數(shù)據(jù)了潮瓶；你要用哪個序列號作為起始數(shù)據(jù)段來回應(yīng)我。- 主機A收到這個數(shù)據(jù)段后钙姊，再發(fā)送一個確認應(yīng)答毯辅，確認已收到主機B 的數(shù)據(jù)段：
我已收到回復(fù)，我現(xiàn)在要開始傳輸實際數(shù)據(jù)了煞额。
這樣3次握手就完成了,主機A和主機B 就可以傳輸數(shù)據(jù)了.
4. 為什么要三次握手思恐？為什么不是兩次沾谜？
為了防止已失效的連接請求報文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯誤胀莹。
5. 四次揮手的過程
- 當(dāng)主機A完成數(shù)據(jù)傳輸后基跑，將控制位FIN置1，提出停止TCP連接的請求描焰；
數(shù)據(jù)發(fā)完畢媳否，但還可接收數(shù)據(jù)，請求斷開連接- 主機B收到FIN后對其作出響應(yīng)荆秦，確認這一方向上的TCP連接將關(guān)閉篱竭，將ACK置1；
請求收到萄凤，同意斷開室抽，不再接收你的數(shù)據(jù)搪哪，但還可以繼續(xù)給你發(fā)數(shù)據(jù)- 由B端再提出反方向的關(guān)閉請求靡努，將FIN置1；
我也沒有數(shù)據(jù)要發(fā)給你啦- 主機A對主機B的請求進行確認晓折，將ACK置1惑朦，雙方向的關(guān)閉結(jié)束。
我也不再接收數(shù)據(jù)漓概，連接斷開
6. 為什么要四次揮手漾月？
因為沒有數(shù)據(jù)要發(fā)送了，不代表沒有數(shù)據(jù)要接收了胃珍×褐祝可能還有沒有接收完成的數(shù)據(jù)。
HTTP
1. HTTP的特點是什么觅彰？
無狀態(tài)吩蔑、無連接。
構(gòu)建與TCP/IP之上填抬。
（客戶端發(fā)送的每次請求都需要服務(wù)器回送響應(yīng)烛芬，在請求結(jié)束后，會主動釋放連接飒责。）
2. HTTP有哪些類型赘娄？
請求、響應(yīng)宏蛉。
3. HTTP請求
HTTP請求常用方法
GET遣臼，POST，PUT拾并， DELETE揍堰。
（查詢蚌讼，修改，增添个榕，刪除）
HTTP請求組成篡石？
狀態(tài)行、請求頭西采、請求正文
GET報文：
- 狀態(tài)行：
GET /books... HTTP/1.1- 請求方式：
GET - 路徑：
/books... - 協(xié)議：
HTTP/1.1
- 請求方式：
- 請求頭：
- 主機名：
Host - 代理信息：
User-Agent - 連接狀態(tài)：
Connection
- 主機名：
- 請求正文：
- 空（GET請求的正文一般為空凰萨，因為它的參數(shù)放在URL中）
POST請求
- 狀態(tài)行：
POST HTTP/1.1- 請求方式：
POST - 協(xié)議：
HTTP/1.1
- 請求方式：
- 請求頭：
- 主機名：
Host - 代理信息：
User-Agent - 內(nèi)容類型：
Content-Type - 內(nèi)容長度：
Content-Length - 連接狀態(tài)：
Connection
- 主機名：
- 請求正文：
sex=man&name=Professional
GET與POST的區(qū)別
- 參數(shù)位置不同
GET參數(shù)在URL中；
POST參數(shù)在正文中械馆。 - 受URL長度限制胖眷，GET參數(shù)數(shù)量有限；
- GET不安全霹崎；
POST安全珊搀。 - GET可以被緩存，可以被收藏為書簽尾菇；
POST可以被緩存境析，不可以被收藏為書簽。
4. HTTP響應(yīng)
HTTP響應(yīng)的組成派诬？
狀態(tài)行劳淆、響應(yīng)頭、響應(yīng)正文
XXX狀態(tài)碼的含義默赂？
1xx : 表示請求已經(jīng)接受了沛鸵，繼續(xù)處理。
2xx : 表示請求已經(jīng)處理掉了缆八。
3xx : 重定向曲掰。
4xx : 一般表示客戶端有錯誤，請求無法實現(xiàn)奈辰。
5xx : 一般為服務(wù)器端的錯誤栏妖。
（狀態(tài)行中包含一個狀態(tài)碼，用來表示服務(wù)器對客戶端響應(yīng)的結(jié)果冯挎。）
常見的狀態(tài)碼（記得就記得底哥，不記得就說12345分別是什么）
200 OK 客戶端請求成功。
301 Moved Permanently 請求永久重定向房官。
302 Moved Temporarily 請求臨時重定向趾徽。
304 Not Modified 文件未修改，可以直接使用緩存的文件翰守。
400 Bad Request 由于客戶端請求有語法錯誤孵奶，不能被服務(wù)器所理解。
401 Unauthorized 請求未經(jīng)授權(quán)蜡峰，無法訪問了袁。
403 Forbidden 服務(wù)器收到請求朗恳，但是拒絕提供服務(wù)。服務(wù)器通常會在響應(yīng)正文中給出不提供服務(wù)的原因载绿。
404 Not Found 請求的資源不存在粥诫，比如輸入了錯誤的URL。
500 Internal Server Error 服務(wù)器發(fā)生不可預(yù)期的錯誤崭庸，導(dǎo)致無法完成客戶端的請求怀浆。
503 Service Unavailable 服務(wù)器當(dāng)前不能夠處理客戶端的請求，在一段時間之后怕享，服務(wù)器可能會恢復(fù)正常执赡。
5. 會話追蹤
（HTTP 協(xié)議是”無狀態(tài)”的協(xié)議，它不能保存客戶的信息函筋，即一次響應(yīng)完成之后連接就斷開了沙合，下一次的請求需要重新連接，這樣就需要判斷是否是同一個用戶跌帐，所以才有會話跟蹤技術(shù)來實現(xiàn)這種要求首懈。）
實現(xiàn)會話追蹤的方法？
URL重寫含末、隱藏表單域猜拾、Cookie即舌、Session
URL 重寫：URL 重寫技術(shù)就是在 URL 結(jié)尾添加一個附加數(shù)據(jù)以標(biāo)識該會話佣盒，把會話 ID 通過 URL 的信息傳遞過去，以便在服務(wù)器進行識別不同的用戶顽聂。
隱藏表單域：將會話ID添加到HTML表單元素中提交到服務(wù)器肥惭，此表單元素并不在客戶端顯示。
Cookie：Cookie 是 Web 服務(wù)器發(fā)送給客戶端的一小段信息紊搪，客戶端請求時可以讀取該信息發(fā)送給服務(wù)器端蜜葱，進而進行用戶的識別，對于客戶端的每次請求耀石，服務(wù)器都會將 Cookie 發(fā)送到客戶端牵囤，客戶端保存下來，以便下次使用滞伟。
Session：在服務(wù)器端會創(chuàng)建一個 session 對象揭鳞，產(chǎn)生一個 sessionID 來標(biāo)識這個 session 對象，然后將這個 sessionID 放入到 Cookie 中發(fā)送到客戶端梆奈，下一次訪問時野崇，sessionID 會發(fā)送到服務(wù)器，在服務(wù)器端進行識別不同的用戶亩钟。
Cookie與Session的區(qū)別乓梨？
- （講一下Cookie怎樣做鳖轰、Session怎樣做）
- Session的實現(xiàn)依賴于Cookie，如果Cookie被禁用扶镀，那么session也將失效蕴侣。
