# 傳統以太網幀
1500 + 14（頭） + 4 （CRC） = 1518 （bytes）
# MSS和MTU
MSS是TCP連接在SYN時進行協商的，代表的最大數據長度，1460的計算是指 1500減去20字節IP頭長度和20字節TCP頭長度
# 802.11幀（MPDU，MAC PDU）類型：管理幀，控制幀，數據幀
管理幀：用於創建、維持、終止站和接入點之間的連接；確定是否採用加密、傳輸網絡名稱（SSID/ESSID）、支持哪種傳輸速率、採用的時間數據庫。
控制幀：RTS（請求發送），CTS（明確發送）/ACK（確認）；RTS和CTS通過放緩傳輸來進行流量控制，當啓動RTS/CTS時，一個站在發送數據幀之前發送一個RTS幀，當接收方願意接收額外的流量時，響應一個CTS幀。組播或者廣播幀沒有ACK確認，以防止"ACK爆炸"。
數據幀：數據幀分片，聚合，片偏移
# 802.11省電模式（PSM）
AP發送 “信標幀” （一種管理幀）來提供不同信息，如SSID、信道和認證信息。某站執行PSM後，直到接收到下一個AP信標幀，才通信會甦醒過來，並確認AP中是否有爲它緩存的幀。
# IP協議的設計目標
將網絡層軟件使用的地址和底層網絡硬件使用的地址進行轉換，爲跨越不同類型物理網絡的分組交換提供互操作。
# ARP 和 RARP
地址解析是發現兩個地址之間的映射關係的過程。ARP提供網絡層邏輯地址到相關硬件地址的動態映射（可能會隨時間變化）。RARP用於缺少磁盤驅動器的系統，在引導時獲取設備的硬件地址。ARP屬於廣播，只能用於同一子網。點到點鏈路（PPP）不使用ARP，在鏈路建立後，鏈路兩端通知正在使用的地址，由於不涉及硬件地址，因此不需要地址解析或者ARP。
ARP緩存：維護網絡層地址到硬件地址的最新映射，使得ARP高效運行，正常到期時間是20min。"arp -a"查詢。
代理ARP（混雜ARP、ARP黑客）：使一個系統可回答不同主機的ARP請求。它使ARP請求的發送者認爲作出響應的系統就是目的主機，但實際目的主機可能在其他地方或者不存在。
免費ARP：ARP請求方請求和通告的IP地址都是請求方的IP地址，兩個作用：確認是否收到應答以確定是否出現IP地址衝突；ARP接收方通過ARP請求更新自己的ARP緩存。
ARP攻擊：代理ARP；ARP緩存靜態條目處理。
# IPv4 / IPv6頭
IPv4頭長度：20 ~ 60 (15 * 4)
IPv6頭長度：40（定長，地址長度128位）；擴展頭部可以在需要時添加，通過 “下一個頭部” 來進行無限擴展，擴展頭部的類型可以是IPv6擴展頭部或者是傳輸層頭部。
# IP數據報長度
由16位長度字段控制，最大長度65535字節（包括頭長）。以太網會將短幀填充到最小長度（64字節），以太網最小有效載荷爲46字節，但IP數據報最小長度爲20字節，所以IP需要長度字段來確定以太網幀中IP數據報的真正長度。
# IP轉發
IP層包括一些位於內存中的信息，通常稱作路由表或轉發表，每次轉發一個數據報需要從中查找信息。當一個網絡接口接收到一個數據報時，IP層首先檢查目的地址是否是自己的IP地址或者是可以接收流量的其他地址（如IP廣播或組播地址），如果是，則IP數據報交付給IPv4頭部協議字段或者IPv6頭部的 “下一個頭部” 字段指定的協議模塊。如果數據報的目的地址不是本地IP模塊使用的IP地址：如果IP層配置成一臺路由器，則轉發該數據報，作爲一個輸出的數據報處理；否則默默丟棄，對於ICMP消息，可能發送回源節點，以表明一個錯誤。
# 路由表
包含：目的地（32位IPv4，或者128位IPv6）、掩碼、下一跳、接口
不包含任何目的地的完整轉發路徑，指明下一跳比該轉發系統更接近目的地，並且下一跳路由器與執行轉發的系統直接連接（在同一個子網中或者PPP鏈路的兩端）。數據報不會在網絡中循環，知道TTL或者跳數限制到期。
# IP直接交付和間接交付
直接交付：目的IP在同一子網中或者PPP鏈路對端，查找路由表發現下一跳的IP爲本機IP，則IP數據報被鏈路層封裝，經過ARP請求獲取目的地的鏈路層地址進行發送。
間接交付：涉及路由器，數據轉發到這臺路由器中，並使用路由器的鏈路層地址作爲目的地址，路由器的IP地址沒有出現在IP數據報中（除非路由器自己是源主機或目的主機，或使用源路由）。
# IP攻擊
基於選項操作，由於一個或多個IP頭部字段無效，可以使路由器崩潰或者性能下降。
僞造源路由地址，早期的訪問控制機制基於源IP地址。
ICMP攻擊。
Internet服務基本要素
IP地址，子網掩碼，DNS服務器IP，路由器IP。這些都是通過DHCP獲取的。
# DHCPv4過程
協議：UDP/IPv4，客戶端端口：68，服務器端口：67，服務器IP：255.255.255.255（有限廣播地址）
DHCPDISCOVER -> DHCPOFFER（IP、DNS、Gateway、子網掩碼、租用時間T、更新時間T1（T / 2）、重新綁定時間T2（7T / 8）） -> DHCPREQUEST -> DHCPACK -> ARP（ACD警告） -> DHCPDECLINE -----------（10s）-------> DHCPDISCOVER
拒絕：DHCPNAK 放棄：DHCPRELEASE 獲取除地址外的其他信息：DHCPINFORM
地址續約：DHCPREQUEST
# 網絡地址轉換（NAT，Network Address Translation）
NAT使得互聯網地址不需要全球唯一，在互聯網的不同部分（地址範圍）可被重複使用，緩解了IP地址耗盡的問題。
缺點：互聯網上的用戶無法直接訪問處於NAT內部的具有私有地址的主機。需要跟蹤每個關聯的或連接的連接狀態，其操作貫穿多個協議層，修改IP層地址的同時也要修改傳輸層的校驗碼。
NAT：利用地址池中的地址重寫NAT內部請求的IP地址，不重寫端口號
NAPT（Network Address Port Translation）：也稱作IP僞裝，使用傳輸層標識符（TCP / UDP端口，ICMP查詢標識符）來確定一個特定的外來數據包到底和NAT內部的哪臺私有主機關聯。將所有NAT主機的IP地址都重寫一個IP地址，有時必須重寫端口號或者ICMP標識，以避免衝突。（如：書中P213）
IP分片情況下，對於不是第一個分片，沒有端口號，NAT在這樣的情況下可能會出錯。
# 防火牆
包過濾防火牆：對網絡層和傳輸層報頭中的各個部分進行比較，丟棄或者轉發
代理防火牆：是運行一個或多個應用層網關（Application-Layer Gateway，ALG）的主機，該主機擁有多個網絡接口，能夠在應用層中繼兩個連接/關聯之間的特定類型的流量。不作IP轉發，應用層的TCP/UDP連接在此終止。如HTTP代理防火牆，SOCKS防火牆。
# 防火牆規則
Iptables：使用NetFilter的網絡過濾功能來實現
3個表格：filter，nat，mangle
filter：處理基本的包過濾，包含INPUT，FORWARD，OUTPUT 3條鏈
nat：PREROUTING，OUTPUT，POSTROUTING
mangle：
# ICMP報文類型
有關IP數據報傳遞的ICMP報文（差錯報文）：目的不可達（路徑MTU，PMTUD（ICMP PTB消息））、重定向（更新路由表）、超時（TTL，源路由，traceroute）、參數問題。（傳遞給用戶進程或者傳輸層協議）
有關信息採集和配置的ICMP報文（查詢或信息類報文）：回顯請求 / 回顯應答（ping）、路由器發現（路由器通告、路由器請求）。（操作系統自動處理）
# 以下情況不會響應ICMPv4差錯報文：
ICMPv4差錯報文（除了ICMPv4查詢類報文）、目的地址是IPv4廣播地址或組播地址的數據報、鏈路層廣播的數據報、不是第一個分片的其他分片、源地址不是某個主機的數據報（如零地址，環回地址，廣播地址，組播地址）。
# 使用traceroute進行源路由和路徑MTU發現
使用UDP或ICMP，不斷改變TTL或者MTU，且端口號設定成目的IP主機未使用的端口號。
目的主機不可達 -> 目的端口不可達：確認路徑MTU（改造後的traceroute，設定不同的MTU，P349）
TTL超時 -> 目的端口不可達：確認源路由
# PING如何區分進程
發送主機利用ICMP PING 標識符來分離返回的應答，在UNIX中，常將進程ID放置在標識符中，來確認哪個進程發送。Android中並不是這樣，ID呈現從0/1遞增的方式。
# 與ICMP相關的攻擊
主要分爲3類：泛洪（產生大量流量，如PING 廣播地址，導致針對一臺或多臺計算機的有效的DoS攻擊）、炸彈（發送經過特殊構造的報文，導致IP或者ICMP的處理崩潰）、信息泄露、ICMP重定向使用一個不準確的系統作爲下一跳路由器、ICMP路由器通告一個不準確的路由器、ICMP目的不可達導致拒絕服務（Smack攻擊）。
# 四種IP地址
單播、組播（224.0.0.0 - 239.255.255.255）、任播（是一個IPv4/IPv6單播地址，根據所在的網絡確定不同的主機，任播地址不是Internet中的一臺主機，而是最合適或者最接近的一臺主機）、廣播（255.255.255.255稱爲本地有限廣播）
# 廣播和組播
將分組交付至多個目的地，如DHCP。IPv6支持組播但不支持廣播。一般使用在UDP / ICMPv4 傳輸協議上，TCP不支持廣播和組播。 鏈路層以太網廣播地址（ff:ff:ff:ff:ff:ff），IP廣播最終是被包裝成鏈路層廣播幀中。
廣播尋址 / 組播尋址
組播：任源組播（只要是特定的組播地址，則接收），特定源組播（包含或排除一組特定發送方的組播）
# UDP
不提供差錯糾正、隊列管理、重複消除、流量控制、擁塞控制。提供 差錯檢測（通過傳輸層校驗和）。
優點：無連接，減少開銷，廣播和組播使用UDP進行無連接傳輸
# TCP
# 端口號（16 bit）
IP層根據協議字段或IPv6下一個頭部字段將進入IP層的數據分離到特定的傳輸層協議中，因此端口號在不同的傳輸層協議之間是獨立的，因此，TCP端口號只能被TCP使用，UDP端口號只能被UDP使用，兩個完全不同的服務器可以使用相同的IP地址和端口號，只要使用的傳輸層協議不同即可。
# IP分片 / 重組 （P347）
根據協商的MTU進行分片，只到目的地纔會重組：減輕中間路由器轉發的負擔；每個分片經過的路由器不同，路由器可能沒有能力對分片進行重組。
分片由IPv4頭部的標識（frag）、分片偏移（分片負載的第一個字節在原始IPv4數據中的偏移量，8字節爲單位）、更多分片 來控制。
分片對於防火牆和NAT來說，是一個複雜的因素，因爲端口號只在第一個分片中包含，其他分片不包含傳輸層協議頭部信息。
更大偏移量的分片要比第一個分片優先投遞：接收主機通過片偏移和IPv4數據報長度確定所需緩存空間的最大值。（P348）
# 擁塞控制算法
4個階段：慢啓動，擁塞避免，快重傳，快恢復
# HTTPS，HTTP
通信使用明文，容易被竊聽；不驗證通信方的身份，可能遭遇僞裝；無法證明報文的完整性，可能遭遇篡改。
HTTPS：HTTP + SSL （Secure Socket Layer，安全套接層）
HTTPS = HTTP + 加密 + 認證 + 完整性保護
SSL：數據加密，防止被竊聽；通過第三方頒發的證書來確定服務器和客戶端是真實存在的，這就確定了通信方的身份。
SSL加密和解密（公開密鑰加密）：使用一對非對稱的密鑰（似有密鑰和公開密鑰），發送方使用公開密鑰進行加密，接收方使用似有密鑰解密。
共享密鑰加密：發送方和接收方使用同一個密鑰進行加密和解密。
HTTPS使用共享密鑰和公開密鑰加密方式結合的混合加密機制。公開加密方式處理複雜，利用公開密鑰加密方式傳輸共享密鑰，之後只用共享密鑰加密方式進行加密。
SSL握手：ClentHello -> ServerHello -> Certificate -> ServerHello Done -> ClientKeyExchange -> ChangeCipherSpec -> Handshake Finished -> ChangeCipherSpec -> Handshake Finished
# SSL，TLS
目前基本使用的是SSL 3.0，TLS是以SSL爲原型開發的協議，SSL的加密和解密消耗CPU資源，傳輸消耗網絡資源，因此HTTPS的速度會比HTTP的速度慢2到100倍。
# HTTP身份認證
BASIC認證（基本認證），DIGEST認證（摘要認證），SSL客戶端認證，FormBase認證（基於表單認證）
BASIC認證 & DIGEST認證：服務器發送401狀態碼提示客戶端發送用戶名和密碼組成的Authorization給服務器。對於HTTP而言，沒有對認證信息進行加密，具有危險性。另外，對已進行BASIC認證後的瀏覽器，一般無法實現認證註銷，不靈活。
SSL客戶端認證：需要第三方頒發的證書
表單認證：類似郵箱登陸的方式，由於HTTP是無狀態的協議，需要Cookie對Session進行管理
# Cookie & Session
-
服務器對每個客戶端的連接發送SessionID，客戶端使用表單認證後，服務器使用客戶端的登錄信息進行身份認證，將用戶的認證狀態與SessionID綁定並保存在服務端。
-
服務器向客戶端相應時，在HTTP手部Set-Cookie字段中寫入Session ID
-
客戶端接收服務器端發送來的Session ID 並將其作爲Cookie保存在本地，下次向服務器請求時，客戶端自動發送該Cookie。
-
服務器端根據客戶端發送的Session ID 識別用戶和其登錄狀態
# HTTP的瓶頸
-
一條連接上只可發送一個請求
-
請求只能從客戶端開始。客戶端不可以接收除響應以外的指令
-
請求 / 響應首部未經壓縮就發送，首部信息越多延遲越大
-
發送冗長的首部，每次互相發送相同的首部造成的浪費較多
-
可任意選擇數據壓縮格式，非強制壓縮發送
解決方式：
-
Ajax（異步JavaScript與XML）：利用JS和DOM（Document Object Model），達到局部Web頁面替換加載的異步通信手段。由於只更新一部分頁面，相應中傳輸的數據量會減少。但沒有解決HTTP的實際問題。
-
Comet：使用“延遲應答”的方式實現推送功能。Comet將對客戶端的相應掛起，當服務器端有內容更新時，返回該相應。缺點：爲了保留響應，一次連接的持續時間變長，且爲了維持連接會消耗更多的資源。
-
SPDY：在HTTP（應用層）和SSL（表達層）間加入SPDY會話層，控制對數據的流動。
# SPDY（SpeeDY，發音同speedy）
-
多路複用流：通過單一的TCP連接處理多個HTTP請求，所有請求的處理都在一條TCP連接上完成
-
請求優先級：給請求分配優先級，解決在處理多個請求時，由於低帶寬導致相應慢的問題
-
壓縮HTTP首部：減少通信數據包數量和字節
-
推送功能：支持服務器主動向客戶端推送數據的功能
-
服務器提示功能：服務器可以主動提示客戶端請求所需要的資源，客戶端在資源已緩存的情況下，可以避免不必要的請求。
# okHttp
Interceptors（責任鏈設計模式）：
責任鏈模式是一種對象的行爲模式。在責任鏈模式裏，很多對象由每一個對象對其下家的引用而連接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。發出這個請求的客戶端並不知道鏈上的哪一個對象最終處理這個請求，這使得系統可以在不影響客戶端的情況下動態地重新組織和分配責任。
RetryAndFollowUpInterceptor -> BridgeInterceptor -> CacheInterceptor -> CallServerInterceptor
主要成員對象：
Call：對請求的封裝，有異步請求和同步請求。
Dispatcher：任務調度器
Connection：是RealConnection的父類接口，表示對JDK中的物理socket進行了引用計數封裝，用來控制socket連接
HttpCodec：對Http請求進行編碼，對Http響應進行解碼，由於Http協議有基於HTTP1.0和Http2.0的兩種情況，Http1Code代表基於Http1.0協議的方式，Http2Code代表基於Http2.0協議的方式。
StreamAllocation：用來控制Connections/Streams的資源分配與釋放
RouteDatabase：用來保存連接的錯誤路徑，以便能提升連接的效率。
RetryAndFollowUpInterceptor：負責失敗重試以及重定向的攔截器
BridgeInterceptor：負責把用戶構造的請求轉換爲發送到服務器的請求、把服務器返回的響應轉爲用戶友好的響應的
CacheInterceptor：負責讀取緩存直接返回、更新緩存（DiskLruCache）
ConnectInterceptor：負責和服務器建立連接的
CallServerInterceptor：負責向服務器發送請求數據、從服務器讀取響應數據
OkHttp的複用連接池：
Http有一種叫做keepalive connections的機制，而okHttp支持5個併發socket連接，默認keepalive時間爲5分鐘。
executor線程池：類似於CachedThreadPool，需要注意的是這種線程池的工作隊列採用了沒有容量的SynchronousQueue。
Deque 雙向隊列：雙端隊列同時具有隊列和棧的性質，經常在緩存中被使用，裏面維護了RealConnection也就是Socket物理連接的包裝。
RouteDatabase ：它用來記錄連接失敗的路線名單，當連接失敗時就會把失敗的路線加進去。
# 斷點續傳原理
設定從 2000070 偏移處開始傳輸
httpConnection.setRequestProperty(“RANGE”，“bytes=2000070”);
通過 RandomAccessFile 將文件指針移到偏移處，繼續寫文件
RandomAccess oSavedFile = new RandomAccessFile(“down.zip”，“rw”);
long nPos = 2000070;
// 定位文件指針到 nPos 位置
oSavedFile.seek(nPos);
byte[] b = new byte[1024];
int nRead;
// 從輸入流中讀入字節流，然後寫到文件中
while((nRead=input.read(b，0，1024)) 》 0)
{
oSavedFile.write(b，0，nRead);
}
http://www.pgygho.com/help/fwq/9184.html