分享一個很好的博客：http://www.cnblogs.com/maybe2030/p/4781555.html#_label3
OSI，TCP/IP，五層協議的體系結構，以及各層協議
激活、維持、關閉通信端點之間的機械特性、電氣特性、功能特性以及過程特性。該層為上層協議提供了一個傳輸數據的可靠的物理媒體。簡單的說，物理層確保原始的數據可在各種物理媒體上傳輸。物理層記住兩個重要的設備名稱，中繼器（Repeater，也叫放大器）和集線器。
2）數據鏈路層（Data Link Layer）
數據鏈路層在物理層提供的服務的基礎上向網絡層提供服務，其最基本的服務是將源自網絡層來的數據可靠地傳輸到相鄰節點的目標機網絡層。為達到這一目的，數據鏈路必須具備一系列相應的功能，主要有：如何將數據組合成數據塊，在數據鏈路層中稱這種數據塊為幀（frame），幀是數據鏈路層的傳送單位；如何控制幀在物理信道上的傳輸，包括如何處理傳輸差錯，如何調節發送速率以使與接收方相匹配；以及在兩個網絡實體之間提供數據鏈路通路的建立、維持和釋放的管理。數據鏈路層在不可靠的物理介質上提供可靠的傳輸。該層的作用包括：物理地址尋址、數據的成幀、流量控制、數據的檢錯、重發等。
有關數據鏈路層的重要知識點：
1> 數據鏈路層為網絡層提供可靠的數據傳輸；
2> 基本數據單位為幀；
3> 主要的協議：以太網協議；
4> 兩個重要設備名稱：網橋和交換機。
3）網絡層（Network Layer）
網絡層的目的是實現兩個主機系統之間的數據透明傳送，具體功能包括尋址和路由選擇、連接的建立、保持和終止等。它提供的服務使傳輸層不需要了解網絡中的數據傳輸和交換技術。如果您想用盡量少的詞來記住網絡層，那就是“路徑選擇、路由及邏輯尋址”。
網絡層中涉及眾多的協議，其中包括最重要的協議，也是TCP/IP的核心協議——IP協議。IP協議非常簡單，僅僅提供不可靠、無連接的傳送服務。IP協議的主要功能有：無連接數據報傳輸、數據報路由選擇和差錯控制。與IP協議配套使用實現其功能的還有地址解析協議ARP、逆地址解析協議RARP、因特網報文協議ICMP、因特網組管理協議IGMP。具體的協議我們會在接下來的部分進行總結，有關網絡層的重點為：
1> 網絡層負責對子網間的數據包進行路由選擇。此外，網絡層還可以實現擁塞控制、網際互連等功能；
2> 基本數據單位為IP數據報；
3> 包含的主要協議：
IP協議（Internet Protocol，因特網互聯協議）;
ICMP協議（Internet Control Message Protocol，因特網控制報文協議）;
ARP協議（Address Resolution Protocol，地址解析協議）可看成是跨網絡層和鏈路層的協議;
RARP協議（Reverse Address Resolution Protocol，逆地址解析協議）。
4> 重要的設備：路由器。
4）傳輸層（Transport Layer）
第一個端到端，即主機到主機的層次。傳輸層負責將上層數據分段並提供端到端的、可靠的或不可靠的傳輸。此外，傳輸層還要處理端到端的差錯控制和流量控制問題。
5）會話層
會話層管理主機之間的會話進程，即負責建立、管理、終止進程之間的會話。會話層還利用在數據中插入校驗點來實現數據的同步。
6）表示層
表示層對上層數據或信息進行變換以保證一個主機應用層信息可以被另一個主機的應用程序理解。表示層的數據轉換包括數據的加密、壓縮、格式轉換等。
7）應用層
是最靠近用戶的OSI層，為用戶的應用程序提供網絡服務的接口。將用戶的操作通過應用程序轉換成為服務，並匹配一個相應的服務協議發送給傳輸層。
注：我們在傳輸數據時，可以只使用（傳輸層）TCP/IP協議，但是那樣的話，如果沒有應用層，便無法識別數據內容，如果想要使傳輸的數據有意義，則必須使用到應用層協議。
會話層、表示層和應用層重點：
1> 數據傳輸基本單位為報文；
2> 包含的主要協議：FTP（文件傳送協議）、Telnet（遠程登錄協議）、DNS（域名解析協議）、SMTP（郵件傳送協議），POP3協議（郵局協議），HTTP協議（Hyper Text Transfer Protocol）。
IP地址
1）網絡地址
IP地址由網絡號（包括子網號）和主機號組成，網絡地址的主機號為全0，網絡地址代表着整個網絡。
2）廣播地址
廣播地址通常稱為直接廣播地址，是為了區分受限廣播地址。
廣播地址與網絡地址的主機號正好相反，廣播地址中，主機號為全1。當向某個網絡的廣播地址發送消息時，該網絡內的所有主機都能收到該廣播消息。
3）組播地址
D類地址就是組播地址。
先回憶下A，B，C，D類地址吧：
A類地址以0開頭，第一個字節作為網絡號，地址范圍為：0.0.0.0~127.255.255.255；(modified @2016.05.31)
B類地址以10開頭，前兩個字節作為網絡號，地址范圍是：128.0.0.0~191.255.255.255;
C類地址以110開頭，前三個字節作為網絡號，地址范圍是：192.0.0.0~223.255.255.255。
D類地址以1110開頭，地址范圍是224.0.0.0~239.255.255.255，D類地址作為組播地址（一對多的通信）；
E類地址以1111開頭，地址范圍是240.0.0.0~255.255.255.255，E類地址為保留地址，供以后使用。
注：只有A,B,C有網絡號和主機號之分，D類地址和E類地址沒有划分網絡號和主機號。
4）255.255.255.255
該IP地址指的是受限的廣播地址。受限廣播地址與一般廣播地址（直接廣播地址）的區別在於，受限廣播地址只能用於本地網絡，路由器不會轉發以受限廣播地址為目的地址的分組；一般廣播地址既可在本地廣播，也可跨網段廣播。例如：主機192.168.1.1/30上的直接廣播數據包后，另外一個網段192.168.1.5/30也能收到該數據報；若發送受限廣播數據報，則不能收到。
注：一般的廣播地址（直接廣播地址）能夠通過某些路由器（當然不是所有的路由器），而受限的廣播地址不能通過路由器。
5）0.0.0.0
常用於尋找自己的IP地址，例如在我們的RARP，BOOTP和DHCP協議中，若某個未知IP地址的無盤機想要知道自己的IP地址，它就以255.255.255.255為目的地址，向本地范圍（具體而言是被各個路由器屏蔽的范圍內）的服務器發送IP請求分組。
6）回環地址
127.0.0.0/8被用作回環地址，回環地址表示本機的地址，常用於對本機的測試，用的最多的是127.0.0.1。
7）A、B、C類私有地址
私有地址(private address)也叫專用地址，它們不會在全球使用，只具有本地意義。
A類私有地址：10.0.0.0/8，范圍是：10.0.0.0~10.255.255.255
B類私有地址：172.16.0.0/12，范圍是：172.16.0.0~172.31.255.255
C類私有地址：192.168.0.0/16，范圍是：192.168.0.0~192.168.255.255
子網掩碼及網絡划分
隨着互連網應用的不斷擴大，原先的IPv4的弊端也逐漸暴露出來，即網絡號占位太多，而主機號位太少，所以其能提供的主機地址也越來越稀缺，目前除了使用NAT在企業內部利用保留地址自行分配以外，通常都對一個高類別的IP地址進行再划分，以形成多個子網，提供給不同規模的用戶群使用。
這里主要是為了在網絡分段情況下有效地利用IP地址，通過對主機號的高位部分取作為子網號，從通常的網絡位界限中擴展或壓縮子網掩碼，用來創建某類地址的更多子網。但創建更多的子網時，在每個子網上的可用主機地址數目會比原先減少。
什么是子網掩碼？
子網掩碼是標志兩個IP地址是否同屬於一個子網的，也是32位二進制地址，其每一個為1代表該位是網絡位，為0代表主機位。它和IP地址一樣也是使用點式十進制來表示的。如果兩個IP地址在子網掩碼的按位與的計算下所得結果相同，即表明它們共屬於同一子網中。
在計算子網掩碼時，我們要注意IP地址中的保留地址，即“ 0”地址和廣播地址，它們是指主機地址或網絡地址全為“ 0”或“ 1”時的IP地址，它們代表着本網絡地址和廣播地址，一般是不能被計算在內的。
子網掩碼的計算：
對於無須再划分成子網的IP地址來說，其子網掩碼非常簡單，即按照其定義即可寫出：如某B類IP地址為 10.12.3.0，無須再分割子網，則該IP地址的子網掩碼255.255.0.0。如果它是一個C類地址，則其子網掩碼為 255.255.255.0。其它類推，不再詳述。下面我們關鍵要介紹的是一個IP地址，還需要將其高位主機位再作為划分出的子網網絡號，剩下的是每個子網的主機號，這時該如何進行每個子網的掩碼計算。
下面總結一下有關子網掩碼和網絡划分常見的面試考題：
1）利用子網數來計算
在求子網掩碼之前必須先搞清楚要划分的子網數目，以及每個子網內的所需主機數目。
(1) 將子網數目轉化為二進制來表示;
如欲將B類IP地址168.195.0.0划分成27個子網：27=11011；
(2) 取得該二進制的位數，為N；
該二進制為五位數，N = 5
(3) 取得該IP地址的類子網掩碼，將其主機地址部分的的前N位置1即得出該IP地址划分子網的子網掩碼。
將B類地址的子網掩碼255.255.0.0的主機地址前5位置 1，得到 255.255.248.0
2）利用主機數來計算
如欲將B類IP地址168.195.0.0划分成若干子網，每個子網內有主機700台：
(1) 將主機數目轉化為二進制來表示；
700=1010111100；
(2) 如果主機數小於或等於254（注意去掉保留的兩個IP地址），則取得該主機的二進制位數，為N，這里肯定 N<8。如果大於254，則 N>8，這就是說主機地址將占據不止8位；
該二進制為十位數，N=10；
(3) 使用255.255.255.255來將該類IP地址的主機地址位數全部置1，然后從后向前的將N位全部置為 0，即為子網掩碼值。
將該B類地址的子網掩碼255.255.0.0的主機地址全部置1，得到255.255.255.255，然后再從后向前將后 10位置0,即為：11111111.11111111.11111100.00000000，即255.255.252.0。這就是該欲划分成主機為700台的B類IP地址 168.195.0.0的子網掩碼。
3）還有一種題型，要你根據每個網絡的主機數量進行子網地址的規划和計算子網掩碼。這也可按上述原則進行計算。
比如一個子網有10台主機，那么對於這個子網需要的IP地址是：
10＋1＋1＋1＝13
注意：加的第一個1是指這個網絡連接時所需的網關地址，接着的兩個1分別是指網絡地址和廣播地址。
因為13小於16（16等於2的4次方），所以主機位為4位。而256－16＝240，所以該子網掩碼為255.255.255.240。
如果一個子網有14台主機，不少人常犯的錯誤是：依然分配具有16個地址空間的子網，而忘記了給網關分配地址。這樣就錯誤了，因為14＋1＋1＋1＝17，17大於16，所以我們只能分配具有32個地址（32等於2的5次方）空間的子網。這時子網掩碼為：255.255.255.224。
ARP/RARP協議
地址解析協議，即ARP（Address Resolution Protocol），是根據IP地址獲取物理地址的一個TCP/IP協議。主機發送信息時將包含目標IP地址的ARP請求廣播到網絡上的所有主機，並接收返回消息，以此確定目標的物理地址；收到返回消息后將該IP地址和物理地址存入本機ARP緩存中並保留一定時間，下次請求時直接查詢ARP緩存以節約資源。地址解析協議是建立在網絡中各個主機互相信任的基礎上的，網絡上的主機可以自主發送ARP應答消息，其他主機收到應答報文時不會檢測該報文的真實性就會將其記入本機ARP緩存；由此攻擊者就可以向某一主機發送偽ARP應答報文，使其發送的信息無法到達預期的主機或到達錯誤的主機，這就構成了一個ARP欺騙。ARP命令可用於查詢本機ARP緩存中IP地址和MAC地址的對應關系、添加或刪除靜態對應關系等。
ARP協議工作流程：
逆地址解析協議，即RARP，功能和ARP協議相對，其將局域網中某個主機的物理地址轉換為IP地址，比如局域網中有一台主機只知道物理地址而不知道IP地址，那么可以通過RARP協議發出征求自身IP地址的廣播請求，然后由RARP服務器負責回答。
RARP協議工作流程：
（1）給主機發送一個本地的RARP廣播，在此廣播包中，聲明自己的MAC地址並且請求任何收到此請求的RARP服務器分配一個IP地址；
（2）本地網段上的RARP服務器收到此請求后，檢查其RARP列表，查找該MAC地址對應的IP地址；
請簡述TCP/UDP的區別
TCP和UDP是OSI模型中的運輸層中的協議。TCP提供可靠的通信傳輸，而UDP則常被用於讓廣播和細節控制交給應用的通信傳輸。
兩者的區別大致如下：
- TCP面向連接，UDP面向非連接即發送數據前不需要建立鏈接
- TCP提供可靠的服務（數據傳輸），UDP無法保證
- TCP面向字節流，UDP面向報文
- TCP數據傳輸慢，UDP數據傳輸快
- TCP提供一種面向連接的、可靠的字節流服務
- 在一個TCP連接中，僅有兩方進行彼此通信，因此廣播和多播不能用於TCP
- TCP使用校驗和，確認和重傳機制來保證可靠傳輸
- TCP使用累積確認
- TCP使用滑動窗口機制來實現流量控制，通過動態改變窗口的大小進行擁塞控制
TCP和UDP的應用場景
TCP：當對網絡通訊質量有要求的時候，比如：整個數據要准確無誤的傳遞給對方，這往往用於一些要求可靠的應用，比如HTTP、HTTPS、FTP等傳輸文件的協議，POP、SMTP等郵件傳輸的協議。
在日常生活中，常見使用TCP協議的應用如：瀏覽器，用的HTTP；FlashFXP，用的FTP；Outlook，用的POP、SMTP；Putty，用的Telnet、SSH；QQ文件傳輸
UDP：當強調傳輸性能而不是傳輸的完整性時， 要求網絡通訊速度能盡量的快。如：QQ語音 QQ視頻等。
TCP對應的協議和UDP對應的協議
TCP對應的協議：
- FTP：定義了文件傳輸協議，使用21端口。
- Telnet：一種用於遠程登陸的端口，使用23端口，用戶可以以自己的身份遠程連接到計算機上，可提供基於DOS模式下的通信服務。
- SMTP：郵件傳送協議，用於發送郵件。服務器開放的是25號端口。
- POP3：它是和SMTP對應，POP3用於接收郵件。POP3協議所用的是110端口。
- HTTP：是從Web服務器傳輸超文本到本地瀏覽器的傳送協議，端口默認80。
UDP對應的協議：
- DNS：用於域名解析服務，將域名地址轉換為IP地址。DNS用的是53號端口。
- SNMP：簡單網絡管理協議，使用161號端口，是用來管理網絡設備的。由於網絡設備很多，無連接的服務就體現出其優勢。
- TFTP(Trival File TransferProtocal)，簡單文件傳輸協議，該協議在熟知端口69上使用UDP服務。
為什么 TCP 叫數據流模式？ UDP 叫數據報模式？
- 所謂的“流模式”，是指TCP發送端發送幾次數據和接收端接收幾次數據是沒有必然聯系的，比如你通過 TCP連接給另一端發送數據，你只調用了一次 write，發送了100個字節，但是對方可以分10次收完，每次10個字節；你也可以調用10次write，每次10個字節，但是對方可以一次就收完。
- 原因：這是因為TCP是面向連接的，一個 socket 中收到的數據都是由同一台主機發出，且有序地到達，所以每次讀取多少數據都可以。
- 所謂的“數據報模式”，是指UDP發送端調用了幾次 write，接收端必須用相同次數的 read 讀完。UDP是基於報文的，在接收的時候，每次最多只能讀取一個報文，報文和報文是不會合並的，如果緩沖區小於報文長度，則多出的部分會被丟棄。
- 原因：這是因為UDP是無連接的，只要知道接收端的 IP 和端口，任何主機都可以向接收端發送數據。 這時候，如果一次能讀取超過一個報文的數據， 則會亂套。
TCP中的流量控制和擁塞控制
- 流量控制主要針對的是端到端傳輸中控制流量大小並保證傳輸可靠性（未收到ack就不滑動）。流量控制往往是指點對點通信量的控制，所要做的是抑制發送端發送數據的速率。
- 擁塞控制主要是一個全局性過程，涉及到所有主機，路由器，以及與降低網絡傳輸性能有關的所有因素。防止過多的數據注入到網絡中。如果有發生丟包則通過擁塞控制減小窗口，確定出合適(慢啟動 擁塞避免 快重傳 快恢復)的擁塞窗口（增性加乘性減）。
詳見博客鏈接（重點）以及《計算機網絡》（謝希仁）。
說一說TCP的三次握手和四次揮手
在TCP/IP協議中，TCP協議提供可靠的連接服務，連接是通過三次握手進行初始化的。三次握手的目的是同步連接雙方的序列號和確認號並交換TCP窗口大小信息
- 核心思想：讓雙方都證實對方能發收。知道對方能收是因為收到對方的因為收到信息之后發的回應(ACK)。
請簡單說一下你了解的端口及對應的服務
端口詳解鏈接（百度百科）
端口
注意區別硬件端口。
- 軟件端口是應用層的各種協議進程與運輸實體進行層間交互的一種地址。
- 端口號只具有本地意義，它只為標志計算機應用層中的各個進程在和運輸層交互時的層間接口，在互聯網不同計算機中，相同的端口號是沒有關聯的。
- 兩個計算機的進程相互通信，不僅需要知道對方的IP地址（為了找到對方計算機），還要知道對方的端口號（為了找到對方計算機中的應用進程）
- 兩大類：1.服務器端使用的端口號（常用熟知）2.客戶端使用的端口號（短暫）。
TCP如何實現可靠性傳輸
確認機制、重傳機制、滑動窗口。
UDP如何實現可靠性傳輸
傳輸層無法保證數據的可靠傳輸，只能通過應用層來實現了。實現的方式可以參照tcp可靠性傳輸的方式，只是實現不在傳輸層，實現轉移到了應用層。
實現確認機制、重傳機制、窗口確認機制。
如果你不利用linux協議棧以及上層socket機制，自己通過抓包和發包的方式去實現可靠性傳輸，那么必須實現如下功能：
發送：包的分片、包確認、包的重發
接收：包的調序、包的序號確認
注：
1）給數據包編號，按照包的順序接收並存儲；
2）接收端接收到數據包后發送確認信息給發送端，發送端接收確認數據以后再繼續發送下一個包，如果接收端收到的數據包的編號不是期望的編號，則要求發送端重新發送。
目前有如下開源程序利用udp實現了可靠的數據傳輸。分別為RUDP、RTP、UDT。
在瀏覽器中輸入www.baidu.com后執行的全部過程
1、應用層：客戶端瀏覽器通過DNS解析到www.baidu.com的IP地址220.181.27.48，通過這個IP地址找到客戶端到服務器的路徑。客戶端瀏覽器發起一個HTTP會話到220.161.27.48，然后通過TCP進行封裝數據包，輸入到網絡層。
- DNS解析過程
- HTTP請求與響應
2、運輸層：在客戶端的傳輸層，把HTTP會話請求分成報文段，添加源和目的端口，如服務器使用80端口監聽客戶端的請求，客戶端由系統隨機選擇一個端口如5000，與服務器進行交換，服務器把相應的請求返回給客戶端的5000端口。然后使用IP層（網絡層）的IP地址查找目的端。
3、網絡層：客戶端的網絡層不用關心應用層或者傳輸層的東西，主要做的是通過查找路由表確定如何到達服務器，期間可能經過多個路由器，這些都是由路由器來完成的工作，我不作過多的描述，無非就是通過查找路由表決定通過那個路徑到達服務器。
4、鏈路層：客戶端的鏈路層，包通過鏈路層發送到路由器，通過鄰居協議查找給定IP地址的MAC地址，然后發送ARP請求查找目的地址，如果得到回應后就可以使用ARP的請求應答交換的IP數據包現在就可以傳輸了，然后發送IP數據包到達服務器的地址。
交換機、路由器的概念，並知道各自的用途
交換機
- 在計算機網絡系統中，交換機是針對共享工作模式的弱點而推出的。交換機擁有一條高帶寬的背部總線和內部交換矩陣。交換機的所有的端口都掛接在這條背部總線上，當控制電路收到數據包以后，處理端口會查找內存中的地址對照表以確定目的MAC（網卡的硬件地址）的NIC（網卡）掛接在哪個端口上，通過內部交換矩陣迅速將數據包傳送到目的端口。目的MAC若不存在，交換機才廣播到所有的端口，接收端口回應后交換機會“學習”新的地址，並把它添加入內部地址表中。
- 交換機工作於OSI參考模型的第二層，即數據鏈路層。交換機內部的CPU會在每個端口成功連接時，通過ARP協議學習它的MAC地址，保存成一張ARP表。在今后的通訊中，發往該MAC地址的數據包將僅送往其對應的端口，而不是所有的端口。因此，交換機可用於划分數據鏈路層廣播，即沖突域；但它不能划分網絡層廣播，即廣播域。
路由器
- 路由器（Router）是一種計算機網絡設備，提供了路由與轉發兩種重要機制，可以決定數據包從來源端到目的端所經過的路由路徑（host到host之間的傳輸路徑），這個過程稱為路由；將路由器輸入端的數據包移送至適當的路由器輸出端(在路由器內部進行)，這稱為轉送。路由工作在OSI模型的第三層——即網絡層，例如IP協議。
- 路由器的一個作用是連通不同的網絡，另一個作用是選擇信息傳送的線路。 路由器與交換器的差別，路由器是屬於OSI第三層的產品，交換器是OSI第二層的產品(這里特指二層交換機)。
HTTP（超文本傳輸協議）
HTTP是一個應用層協議，由請求和響應構成，是一個標准的客戶端服務器模型。
HTTP是一個基於TCP/IP通信協議來傳遞數據，默認端口號為80。
HTTP工作原理
HTTP協議定義Web客戶端如何從Web服務器請求Web頁面，以及服務器如何把Web頁面傳送給客戶端。
HTTP 請求/響應的步驟
1、客戶端連接到Web服務器
一個HTTP客戶端，通常是瀏覽器，與Web服務器的HTTP端口（默認為80）建立一個TCP套接字連接。例如，http://www.oakcms.cn。
2、發送HTTP請求
通過TCP套接字，客戶端向Web服務器發送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求數據4部分組成。
3、服務器接受請求並返回HTTP響應
Web服務器解析請求，定位請求資源。服務器將資源復本寫到TCP套接字，由客戶端讀取。一個響應由狀態行、響應頭部、空行和響應數據4部分組成。
4、釋放連接TCP連接
若connection 模式為close，則服務器主動關閉TCP連接，客戶端被動關閉連接，釋放TCP連接;若connection 模式為keepalive，則該連接會保持一段時間，在該時間內可以繼續接收請求;
5、客戶端瀏覽器解析HTML內容
客戶端瀏覽器首先解析狀態行，查看表明請求是否成功的狀態代碼。然后解析每一個響應頭，響應頭告知以下為若干字節的HTML文檔和文檔的字符集。客戶端瀏覽器讀取響應數據HTML，根據HTML的語法對其進行格式化，並在瀏覽器窗口中顯示。
HTTP消息結構
HTTP是基於客戶端/服務端（C/S）的架構模型
客戶端發送一個HTTP請求到服務器的請求消息包括以下格式：請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成，請求報文的一般格式
HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文。
http常見狀態碼有哪些？
狀態碼告知從服務器端返回的請求結果。
-
2開頭狀態碼
2xx (成功)表示成功處理了請求的狀態代碼
200 (成功) 服務器已成功處理了請求。 通常。
-
3開頭狀態碼
3xx (重定向) 表示要完成請求，需要進一步操作。 通常，這些狀態代碼用來重定向。
304 (未修改) 自從上次請求后，請求的網頁未修改過。 服務器返回此響應時，不會返回網頁內容。
-
4開頭狀態碼
4xx(請求錯誤) 這些狀態代碼表示請求可能出錯，妨礙了服務器的處理
1:400 (錯誤請求) 服務器不理解請求的語法。
2:403 (禁止) 服務器拒絕請求。
3:404 (未找到) 服務器找不到請求的網頁。
-
5開頭狀態碼
5xx(服務器錯誤)這些狀態代碼表示服務器在嘗試處理請求時發生內部錯誤。 這些錯誤可能是服務器本身的錯誤，而不是請求出錯
500 (服務器內部錯誤) 服務器遇到錯誤，無法完成請求。
501 (尚未實施) 服務器不具備完成請求的功能。 例如，服務器無法識別請求方法時可能會返回此代碼。
502 (錯誤網關) 服務器作為網關或代理，從上游服務器收到無效響應。
503 (服務不可用) 服務器目前無法使用(由於超載或停機維護)。 通常，這只是暫時狀態。
504 (網關超時) 服務器作為網關或代理，但是沒有及時從上游服務器收到請求。
505 (HTTP 版本不受支持) 服務器不支持請求中所用的 HTTP 協議版本。
重點：200,304,403，404,500HTTP與HTTPS區別
1、https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2、http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
4、http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。
HTTP1.0和HTTP1.1的區別
HTTP長連接與短鏈接
在HTTP/1.0中默認使用短連接。也就是說，客戶端和服務器每進行一次HTTP操作，就建立一次連接，任務結束就中斷連接。當客戶端瀏覽器訪問的某個HTML或其他類型的Web頁中包含有其他的Web資源（如JavaScript文件、圖像文件、CSS文件等），每遇到這樣一個Web資源，瀏覽器就會重新建立一個HTTP會話。
而從HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭加入這行代碼：
Connection:keep-alive
在使用長連接的情況下，當一個網頁打開完成后，客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉，客戶端再次訪問這個服務器時，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現長連接需要客戶端和服務端都支持長連接。
HTTP協議的長連接和短連接，實質上是TCP協議的長連接和短連接。
DNS域名系統，簡單描述其工作原理。
當DNS客戶機需要在程序中使用名稱時，它會查詢DNS服務器來解析該名稱。客戶機發送的每條查詢信息包括三條信息：包括：指定的DNS域名，指定的查詢類型，DNS域名的指定類別。基於UDP服務，端口53. 該應用一般不直接為用戶使用，而是為其他應用服務，如HTTP，SMTP等在其中需要完成主機名到IP地址的轉換。
路由選擇協議
路由選擇協議的任務就是要確定數據報在源與目的地之間采用的路徑。
路由選擇協議分為：靜態的和動態的。Internet中使用的是動態路由選擇協議，在Internet的概念中，將整個互聯網划分為許多個小的自治系統（AS）。AS的最主要的特征：一個AS對其他AS表現出的是一個單一 和一致的路由選擇策略。
由於AS的存在，路由選擇協議又分為兩種：
- 內部網關協議（IGP）：即在一個AS內部使用的路由選擇協議，而這與互聯網中其他AS選用什么路由協議無關。比如：RIP，OSPF
- 外部網關協議（EGP）：若源主機和目的主機不再同一個AS中，就需要使用一種協議將路由選擇信息傳遞到另一個AS中，這就是EGP。比如：BGP。
重傳機制
網絡萬一阻塞了呢？發出去的請求包在規定時間內沒有收到ACK，不管是請求包丟失，還是ACK包丟失，還是網絡延遲，總之，這里都是需要有個重傳機制的。TCP的重傳機制有兩種：超時重傳和快速重傳。
超時重傳
說白了就是在請求包發出去的時候，開啟一個計時器，當計時器達到時間之后，沒有收到ACK，則就進行重發請求的操作，一直重發直到達到重發上限次數或者收到ACK。
快速重傳
還有一種機制就是快速重傳，當接收方收到的數據包是不正常的序列號，那么接收方會重復把應該收到的那一條ACK重復發送，這個時候，如果發送方收到連續3條的同一個序列號的ACK，那么就會啟動快速重傳機制，把這個ACK對應的發送包重新發送一次。具體可以參考：
TCP/IP通信過程（以發送電子郵件為例）
socket通信原理
網絡編程中的基本概念
TCP粘包問題
1 什么是粘包現象
TCP粘包是指發送方發送的若干包數據到接收方接收時粘成一包，從接收緩沖區看，后一包數據的頭緊接着前一包數據的尾。
2 為什么出現粘包現象
（1）發送方原因
我們知道，TCP默認會使用Nagle算法。而Nagle算法主要做兩件事：1）只有上一個分組得到確認，才會發送下一個分組；2）收集多個小分組，在一個確認到來時一起發送。
所以，正是Nagle算法造成了發送方有可能造成粘包現象。
（2）接收方原因
TCP接收到分組時，並不會立刻送至應用層處理，或者說，應用層並不一定會立即處理；實際上，TCP將收到的分組保存至接收緩存里，然后應用程序主動從緩存里讀收到的分組。這樣一 來，如果TCP接收分組的速度大於應用程序讀分組的速度，多個包就會被存至緩存，應用程序讀時，就會讀到多個首尾相接粘到一起的包。
3 什么時候需要處理粘包現象
（1）如果發送方發送的多個分組本來就是同一個數據的不同部分，比如一個很大的文件被分成多個分組發送，這時，當然不需要處理粘包的現象；
（2）但如果多個分組本毫不相干，甚至是並列的關系，我們就一定要處理粘包問題了。
4 如何處理粘包現象
（1）發送方
對於發送方造成的粘包現象，我們可以通過關閉Nagle算法來解決，使用TCP_NODELAY選項來關閉Nagle算法。
（2）接收方
遺憾的是TCP並沒有處理接收方粘包現象的機制，我們只能在應用層進行處理。
（3）應用層處理
應用層的處理簡單易行！並且不僅可以解決接收方造成的粘包問題，還能解決發送方造成的粘包問題。
解決方法就是循環處理：應用程序在處理從緩存讀來的分組時，讀完一條數據時，就應該循環讀下一條數據，直到所有的數據都被處理；但是如何判斷每條數據的長度呢？
兩種途徑：
1）格式化數據：每條數據有固定的格式（開始符、結束符），這種方法簡單易行，但選擇開始符和結束符的時候一定要注意每條數據的內部一定不能出現開始符或結束符；
2）發送長度：發送每條數據的時候，將數據的長度一並發送，比如可以選擇每條數據的前4字節是數據的長度（一個int來儲存數據長度大小），應用層處理時可以根據長度來判斷每條數據的開始和結束。
詳細還可以參考此博客：鏈接
TCP協議中的三次握手四次揮手以及11種狀態轉換
注：