網絡基礎
局域網（LAN）、城域網（MAN）、廣域網（WAN）
拓撲結構：星型網絡、總線型網絡、環型網絡、樹型網絡、星型環型網絡等；
傳輸介質：雙絞線網、同軸電纜網、光纖網和衛星網等；
通信協議三部分組成：語義部分、語法部分、變換規則；
IP（Internet Protocol）又稱互聯網協議，是支持網間互聯的數據報協議。
IP 地址分爲A、B、C、D、E，每個類別的網絡標識和主機標識各有規則。
IP 地址用於唯一地標識網絡上的一個通信實體，但一個通信實體可以有多個通信程序同時提供網絡服務，此時還需要使用端口。
端口 是一個16位的整數。0~65535
- 公認端口：0~1023，緊密綁定一些特定的服務。
- 註冊端口：1024~49151，鬆散地綁定一些服務。
- 動態和/或私有端口：49152~65535
OSI（Open System Interconnect）開放系統互聯參考模型
HTTP & HTTPS
HTTP（HyperText Transfer Protocol，超文本傳輸協議） 協議是基於TCP的應用層協議，不關心數據傳輸的細節，主要是用來規定客戶端和服務端的數據傳輸格式。
HTTPS——HTTP協議的數據傳輸是明文的，是不安全的，HTTPS 使用了 SSL/TLS 協議進行了加密處理。
HTTPS 協議的主要作用分爲兩種：一種是建立一個信息安全通道，來保證數據傳輸的安全；另一種是確認網站的真實性。
HTTP 與 HTTPS 區別
- https 協議需要到 CA 申請證書。
- HTTP 協議運行在 TCP 之上，所有傳輸的內容都是明文，HTTPS 運行在 SSL/TLS 之上，SSL/TLS 運行在 TCP 之上，所有傳輸的內容都經過加密的。
- 使用不同的連接方式，端口不一樣，http 是 80，https 是 443。
- HTTPS 可以有效的防止運營商劫持，解決了防劫持的一個大問題。
TCP/IP
TCP/IP協議族裏重要的一點就是分層。
IP
IP 間的通信依賴 MAC 地址。在網絡上，通信的雙方在同一局域網 （LAN）內的情況是很少的，通常是經過多臺計算機和網絡設備中轉 才能連接到對方。而在進行中轉時，會利用下一站中轉設備的 MAC 地址來搜索下一個中轉目標。這時，會採用 ARP 協議（Address Resolution Protocol）。ARP 是一種用以解析地址的協議，根據通信方的 IP 地址就可以反查出對應的 MAC 地址。
TCP
傳輸控制協議（TCP，Transmission Control Protocol）是一種面向連接的、可靠的、基於字節流的傳輸層通信協議。按層次分，TCP 位於傳輸層，提供可靠的字節流服務。
爲了準確無誤地將數據送達目標處，TCP 協議採用了三次握手 （three-way handshaking）策略。握手過程中使用了 TCP 的標誌（flag） —— SYN（synchronize） 和 ACK（acknowledgement）。
TCP 連接 (三次握手)
- 客戶端發送 SYN(SYN=j) 標誌的數據包到服務端，並進入 SYN_SEND 狀態，等待服務端確認。
- 服務端收到 SYN 包，必須確認客戶端的 SYN(ACK=j+1)，同時自己也發送一個 SYN 包(SYN=k)，即 SYN + ACK 包，此時服務器B進入 SYN_RECV 狀態。
- 客戶端收到服務端的 SYN＋ACK 包，向服務端發送確認包 ACK(ACK=k+1)，此包發送完畢，客戶端和服務器進入 ESTABLISHED 狀態，完成三次握手。
TCP 斷開 (四次握手)
- Client 發送 FIN 消息，seq = u (u 爲當前消息序列號，因爲 FIN 消息也必須消耗一次序列號), 狀態：FIN-WAIT-1
- Server 收到 FIN 消息回覆 ACK 消息並帶上當前消息序列號，並等待其他消息發送完畢，狀態：CLOSE-WAIT。Client 收到 ACK 消息，狀態：FIN-WAIT-2
- Server 其他消息發送完畢，發送 FIN 消息並帶上當前序列號 (因爲不確定服務器到底還發送了多少消息，假定 w), 狀態：LAST-ACK。
- Client 收到 FIN 消息回覆 ACK 消息，並進入 TIME-WAIT 狀態。Server 收到 ACK 消息，狀態：CLOSED
DNS
DNS（Domain Name System）服務是和 HTTP 協議一樣位於應用層的協議。它提供域名到 IP 地址之間的解析服務。
URI 和 URL
URI（Uniform Resource Identifier，統一資源標識符）
URL（Uniform Resource Locator，統一資源定位符）
HTTP 響應狀態碼
3 位數字加原因短語。3 位數字中的第一位用來指定狀態的類別，共5種。
- 1xx——信息性狀態碼——接收的請求正在處理
- 2xx——成功狀態碼——請求正常處理完畢
- 3xx——重定向狀態碼——需要進行附加操作以完成請求
- 4xx——客戶端錯誤狀態碼——服務器無法處理請求
- 5xx——服務器錯誤狀態碼——服務器處理請求出錯
200：OK
204：No Content
400：Bad Request
404：Not Found
常見問題
影響一個 HTTP 網絡請求的因素主要有兩個：帶寬和延遲。
爲什麼連接的時候是三次握手，關閉的時候卻是四次握手？
因爲當Server端收到Client端的SYN連接請求報文後，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，“你發的FIN報文我收到了”。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。
如果已經建立了連接，但是客戶端突然出現故障了怎麼辦？
TCP還設有一個保活計時器，顯然，客戶端如果出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求後都會重新復位這個計時器，時間通常是設置爲2小時，若兩小時還沒有收到客戶端的任何數據，服務器就會發送一個探測報文段，以後每隔75秒鐘發送一次。若一連發送10個探測報文仍然沒反應，服務器就認爲客戶端出了故障，接着就關閉連接。
HTTP 發展歷程
HTTP/2.0
2015
二進制傳輸
多路複用
多路複用允許同時通過單一的 HTTP/2 連接發起多重的請求-響應消息。
Header壓縮
HTTP1.0 中，我們使用文本的形式傳輸 header，在 header 中攜帶 cookie 的話，每次都需要重複傳輸幾百到幾千的字節，這着實是一筆不小的開銷。HTTP2.0 中，我們使用了 HPACK（HTTP2頭部壓縮算法）壓縮格式對傳輸的 header 進行編碼，減少了 header 的大小。並在兩端維護了索引表，用於記錄出現過的 header，後面在傳輸過程中就可以傳輸已經記錄過的 header 的鍵名，對端收到數據後就可以通過鍵名找到對應的值。
HTTP/1.1
1997年1月公佈HTTP/1.1。無狀態協議，但爲了實現期望的保持狀態功能，於是引入了 Cookie 技術。
- 緩存處理
- 帶寬優化及網絡連接的使用
- 錯誤通知的管理
- Host頭處理
- 長連接，HTTP 1.1支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲，在HTTP1.1中默認開啓Connection： keep-alive，一定程度上彌補了HTTP1.0每次請求都要創建連接的缺點。
HTTP/1.0
HTTP 正式作爲標準被公佈是在 1996年5月，版本命名爲 HTTP/1.0。