1.計算機網絡體系結構

1.1 OSI體系結構

• 應用層
• 表示層：數(shù)據(jù)壓縮、加密以及數(shù)據(jù)描述
• 會話層：建立及管理會話
• 運輸層
• 網絡層
• 數(shù)據(jù)鏈路層
• 物理層

1.2 TCP/IP體系結構

• 應用層
• 運輸層
• 網際層
• 網絡接口層

1.3 五層協(xié)議體系結構

• 應用層：為特定應用程序提供數(shù)據(jù)傳輸服務
• 運輸層：為進程提供通用數(shù)據(jù)傳輸服務
• 網絡層：為主機提供傳輸服務笨腥。把傳輸層傳遞下來的報文段或者用戶數(shù)據(jù)封裝成分組
• 數(shù)據(jù)鏈路層：為同一鏈路的主機提供數(shù)據(jù)傳輸服務智哀，把網絡層傳下來的分組封裝成幀
• 物理層：盡可能屏蔽傳輸媒體和通信手段的差異，使鏈路層感覺不到這些差異

2.網絡層

2.1 ip地址

• 分類
  1.A類：0開頭，8位網絡號辉巡，24位主機號
  2.B類：10開頭殊者，16位網絡號与境，16位主機號
  3.C類：110開頭，24位網絡號猖吴，8位主機號

2.2 地址解析協(xié)議ARP

ARP實現(xiàn)由IP地址得到MAC地址摔刁。每個主機都有一個ARP高速緩存，里面有本局域網上的各主機和路由器的IP地址到MAC地址的映射表海蔽。當主機A欲向本局域網上的某個主機B發(fā)送IP數(shù)據(jù)報時共屈，就先在其ARP高速緩存中查看有無主機B的IP地址，如果有則可以查到MAC地址党窜，如果沒有拗引，此時主機A會通過廣播的方式請求ARP分組，主機B收到該請求后會發(fā)送ARP相應分組給主機A告知MAC地址幌衣。

2.3 網際控制報文協(xié)議ICMP

為了有效轉發(fā)IP和數(shù)據(jù)報和提高交付的機會矾削。封裝在ip數(shù)據(jù)報中，ping是其一個重要的應用豁护，來測試兩臺主機之間的連通性哼凯。
Ping的原理是通過向目的主機發(fā)送ICMP Echo請求報文，目的主機收到之后會發(fā)送ICMP回答報文楚里。Ping會根據(jù)時間和成功響應的次數(shù)估算出數(shù)據(jù)包往返時間和丟包率断部。

3.運輸層

3.1 TCP

面向連接，提供可靠交付班缎，有流量控制蝴光，擁塞控制，只能是一對一吝梅。

• TCP首部：20個固定字節(jié)虱疏，包括序號、確認號苏携、源端口做瞪、目的端口、數(shù)據(jù)偏移、確認ACK装蓬、同步SYN著拭、終止FIN、窗口牍帚。

  
  
  TCP報文的首部格式

• 應用場景：效率要求低儡遮，準確率要求高的場景。如文件傳輸暗赶，接受郵件鄙币，遠程登陸

三次握手

• 三次握手（三次握手是為了防止失效的連接請求到達服務器，讓服務器錯誤打開連接）：

1. A向B發(fā)送SYN=1的連接請求蹂随，初始序號為X十嘿。
2. B收到報文，如果同意岳锁，向A發(fā)送SYN=1绩衷，ACK=1的確認報文，確認號X+1激率，同時也選擇一個初始序號Y
3. A收到B的報文后咳燕，發(fā)送ACK=1確認報文，確認號Y+1乒躺，序號X+1招盲。

• 三次握手的原因：第三次握手是為了防止失效連接請求到達服務器，讓服務器錯誤打開連接聪蘸∠苄ぃ客戶端發(fā)送的連接請求如果在網絡中滯留，會隔很長時間才收到服務器返回的確認健爬，客戶端等待一個超時重傳時間后，會重新發(fā)送連接請求么介，但這個滯留的請求最終還是會達到服務器娜遵，如果不進行三次握手，服務端會打開第二個連接壤短。如果進行了三次握手设拟，客戶端會忽視服務器發(fā)來的滯留連接請求的確認。

四次揮手

• 四次揮手：

1. A發(fā)送連接釋放報文久脯，F(xiàn)IN=1纳胧。
2. B收到之后發(fā)出確認ACK=1，此時TCP處于半關閉狀態(tài)帘撰，B可向A發(fā)送數(shù)據(jù)跑慕，A不可以發(fā)送
3. B執(zhí)行完接收操作，不再需要連接，發(fā)送連接釋放報文核行，F(xiàn)IN=1,ACK=1牢硅。
4. A收到后發(fā)出確認ACK=1，進入TIME-WAIT狀態(tài)芝雪，等待兩個最大報文存活時間后釋放連接减余。

• 四次揮手的原因：客戶端發(fā)送了釋放連接的報文后，服務器收到報文就會進入到CLOSE-WAIT狀態(tài)惩系，這個狀態(tài)是為了讓服務器接收還未傳送完的數(shù)據(jù)位岔。
• 等待2MSL的原因：
  1.確認最后一個報文到達服務端，如果沒到達會重新發(fā)送
  2.保證本連接內產生的報文全部從網絡消失

3.2 TCP的可靠傳輸

1. TCP給發(fā)送的每一個包進行編號堡牡，接收方對數(shù)據(jù)包進行排序赃承，把有序數(shù)據(jù)傳送給應用層。
2. 校驗和：TCP將保持它首部和數(shù)據(jù)的校驗和悴侵。這是一個端到端的校驗和瞧剖，目的是檢測數(shù)據(jù)在傳輸過程中的任何變化。如果收到段的校驗和有差錯可免，TCP將丟棄這個報文段和不確認收到此報文段抓于。
3. TCP的接收端會丟棄重復的數(shù)據(jù)。
4. 流量控制
5. 擁塞控制
6. 超時重傳：當TCP發(fā)出一個段后浇借，它啟動一個定時器捉撮，等待目的端確認收到這個報文段，如果不能及時收到一個確認將重發(fā)這個報文段妇垢。
7. ARQ協(xié)議

• 滑動窗口：TCP滑動窗口相當于是緩存的一部分巾遭，用來暫時存放字節(jié)流。窗口里面的都是未發(fā)送的或未確認的闯估，如果發(fā)送并接收成功了灼舍，就右移滑動窗口。

• 流量控制：為了控制發(fā)送方發(fā)送速率涨薪，保證接收方來得及接收骑素。通過接收方發(fā)送的確認報文中的窗口字段可以用來控制窗口大小，從而控制發(fā)送速率刚夺。

• 擁塞控制：如果網絡出現(xiàn)擁塞献丑，分組將會丟失，此時發(fā)送方會重傳侠姑，從而導致網絡擁塞度更高创橄。所以需要減少數(shù)據(jù)的發(fā)送，通過慢開始莽红、擁塞避免妥畏、快恢復、快重傳來實現(xiàn)擁塞控制：
  1.慢開始：發(fā)送最初執(zhí)行慢開始，cwnnd(擁塞窗口)=1咖熟，收到確認后圃酵，cwnd翻倍，當cwnd>=ssthresh（慢開始門限）馍管，進入擁塞避免郭赐。
  2.擁塞避免：每次收到確認后，cwnd不再翻倍确沸，而是cwnd=cwnd+1捌锭，如果出現(xiàn)超時，ssthresh=cwnd/2罗捎，重新執(zhí)行慢開始
  3.快重傳：在發(fā)送方观谦，如果收到三個重復確認，此時立即執(zhí)行快重傳桨菜，立即重傳下一個字段豁状。
  4.快恢復：如果只是丟失個別報文段，而不是網絡擁塞倒得，應執(zhí)行快恢復泻红，ssthresh=cwnd/2，cwnd=ssthresh霞掺，直接進入擁塞避免階段谊路。

• ARQ協(xié)議
  1.停止等待ARQ協(xié)議：每發(fā)完一個分組就停止發(fā)送，等待對方確認菩彬。如果過了一段時間缠劝，還是沒有收到確認，說明沒有發(fā)送成功骗灶，需要重新發(fā)送惨恭，直到收到確認后再發(fā)下一個分組。若接收方收到重復分組矿卑，就丟棄該分組喉恋，但同時還要發(fā)送確認。優(yōu)點是實現(xiàn)簡單母廷，缺點是信道利用率低，等待時間長糊肤。
  2.連續(xù)ARQ協(xié)議：發(fā)送方維持一個發(fā)送窗口琴昆，凡位于發(fā)送窗口內的分組可以連續(xù)發(fā)送出去，而不需要等待對方確認馆揉。接收方一般采用累計確認业舍，對按序到達的最后一個分組發(fā)送確認，表明到這個分組位置所有分組都已經正確收到了。優(yōu)點是信道利用率高舷暮，容易實現(xiàn)态罪，即使確認丟失，也不必重傳下面。缺點是不能向發(fā)送方反映出接收方已經正確收到的所有分組的信息复颈。

• TCP粘包：一個數(shù)據(jù)包中包含了發(fā)送端發(fā)送的兩個數(shù)據(jù)包的信息，由于接收端不知道這兩個數(shù)據(jù)包的界限沥割，所以對于接收端很難處理耗啦。

• TCP拆包：一個數(shù)據(jù)包拆成了多個。

• 解決方案：
  1.使用帶消息頭的協(xié)議机杜，消息頭存儲消息開始標識以及消息長度信息帜讲，服務端獲取消息頭的時候解析出消息長度，然后向后讀取該長度的內容
  2.設置定長消息
  3.設置消息邊界椒拗，服務端從網絡流中按消息編輯分離出消息內容

3.3 UDP

無連接似将，沒有阻塞控制，支持一對一蚀苛，一對多在验，多對多。

UDP首部

• UDP首部：只有8個字節(jié)枉阵，包括源端口译红、目的端口、長度和校驗和兴溜。12個字節(jié)的首部是為了計算檢驗和臨時增加的侦厚。
• 應用場景：效率要求高，對準確性要求相對低的場景拙徽。如QQ聊天刨沦，在線視頻，網絡語音電話膘怕，廣播通信

3.4 TCP與UDP的區(qū)別

• TCP面向連接想诅，UDP是無連接的，在發(fā)送數(shù)據(jù)前不需要建立連接
• TCP提供可靠全雙工的通信服務岛心，UDP是半雙工来破，只能單向傳播
• 通過TCP連接可靠傳輸?shù)臄?shù)據(jù)，是可靠忘古、無差錯徘禁、不丟失、不重復且 按序到達的髓堪；UDP是不可靠信道送朱，盡最大努力交付娘荡，不保證可靠交付
• TCP面向字節(jié)流，UDP面向報文
• TCP有擁塞控制驶沼，UDP沒有
• TCP是點到點的炮沐，UDP支持一對一，一對多回怜，多對多
• TCP首部開銷20字節(jié)大年，UDP開銷小，只有8字節(jié)

4.應用層

4.1 DNS

DNS是一個分布式數(shù)據(jù)庫鹉戚，提供了主機名和IP地址之間相互轉換的服務鲜戒。每個站點只保留它自己的那部分數(shù)據(jù)。DNS可以使用UDP或TCP傳輸抹凳，端口號為53遏餐，大多數(shù)情況下使用UDP，只有兩種情況會使用TCP：

• 如果返回的響應超過512字節(jié)

• 區(qū)域傳送（主域名服務器向輔助域名服務器傳送變化的那部分數(shù)據(jù)）

• DNS工作過程：
  1.客戶端提出域名解析請求赢底，并將該請求發(fā)送給本地的域名服務器失都。
  2.本地的域名服務器收到請求后，先查詢本地緩存幸冻，如果有粹庞，直接返回對應的IP地址
  3.如果沒有該記錄，則本地域名服務器就直接把請求發(fā)給根域名服務器洽损，然后根域名服務器再返回給本地域名服務器一個所查詢域的主域名服務器的地址
  4.本地服務器向這個主域名服務器發(fā)送請求庞溜，接收請求的服務器查詢自己的緩存，如果沒有該記錄碑定，則返回相關下級的域名服務器的地址流码。
  5.重復第四步，直到找到正確的記錄
  6.本地域名服務器獲得地址后延刘，將該地址存到緩存中漫试，同時返回結果

4.2 文件傳送協(xié)議FTP

使用TCP進行連接。需要兩個連接來傳送一個文件碘赖。

• 控制連接：服務器打開21端口等待客戶端連接驾荣，客戶端主動連接后，使用這個連接將客戶端命令傳給服務器普泡，并傳回服務器的應答播掷。
• 數(shù)據(jù)連接：用來傳送一個文件數(shù)據(jù)。

4.3 動態(tài)主機配置協(xié)議（DHCP）

DHCP提供了即插即用的聯(lián)網方式撼班，用戶不再需要手動配置IP地址等信息叮趴。DHCP配置的內容不僅是IP地址，還包括子網掩碼权烧、網關IP地址眯亦。

• 工作過程：

1. 客戶端發(fā)送Discover報文，放入UDP中般码，該報文被廣播到同一子網的所有主機上妻率。如果客戶端和DHCP服務器不在同一個子網，就需要使用中繼代理板祝。
2. DHCP服務器收到Discover報文后宫静，發(fā)送Offer報文給客戶端，該報文包含了客戶端所需要的信息券时，因此客戶端需要進行選擇孤里。
3. 如果客戶端選擇了某個DHCP服務器提供的信息，那么就發(fā)送Request報文給該DHCP服務器橘洞。
4. DHCP服務器發(fā)送ACK報文捌袜，表示客戶端此時可以使用提供給它的信息。

4.4 電子郵件協(xié)議

發(fā)送協(xié)議常用SMTP炸枣，讀取協(xié)議常用POP3和IMAP虏等。

4.5 電腦上訪問一個web頁面的過程

1. DNS解析域名，得到對應的IP地址适肠。主機向DNS服務器發(fā)送查詢報文霍衫，此過程中，需要通過網關服務器的IP地址獲得其MAC地址侯养，這過程中需要通過ARP協(xié)議敦跌。路由器將DNS查詢請求轉發(fā)到DNS服務器，解析出IP地址逛揩。
2. 建立TCP連接柠傍。得到了HTTP服務器的IP地址后，與HTTP服務器進行三次握手來建立TCP連接息尺。
3. HTTP請求携兵。連接建立后，瀏覽器生成HTTP GET報文搂誉，交付給HTTP服務器徐紧。
4. HTTP服務器從TCP套接字中讀取HTTP GET報文，生成HTTP響應報文炭懊，將WEB頁面內容放入報文主體中并级，返回給主機。
5. 瀏覽器抽取WEB頁面內容侮腹，進行渲染嘲碧，顯示出來。

5.HTTP

5.1 HTTP報文

• 請求報文
  1.報文首部（請求行父阻、請求首部字段愈涩、通用首部字段望抽、實體首部字段、其他）
  2.空行
  3.報文主體
• 響應報文
  1.報文首部（響應行履婉、響應首部字段煤篙、通用首部字段、實體首部字段毁腿、其他）
  2.空行
  3.報文主體

5.2 狀態(tài)碼

100：請求正在處理辑奈，客戶端可以繼續(xù)發(fā)送請求或忽略這個響應
200：OK
204：請求已經成功處理，但是返回的響應報文不包含實體的主體部分已烤。
301：永久性重定向
302：臨時性重定向
303：臨時性重定向鸠窗，但要求客戶端要用GET獲取資源。
304：請求首部包含條件胯究，如果不滿足條件稍计，則會返回304狀態(tài)碼
400：請求語法錯誤
401：表示發(fā)送的請求需要有認證信息
403：請求被拒絕
404：Not found
500：服務器正在執(zhí)行請求時發(fā)生錯誤

5.3 短連接與長連接

• 長連接：只需要建立一次TCP連接就能進行多次HTTP通信，HTTP1.1后默認唐片，如果要斷開連接丙猬，使用Connection:close；
• 短連接：一次TCP連接只能進行一次HTTP通信费韭，HTTP1.0默認茧球。如果要使用長連接，使用Connection:keep-Alive星持。

5.4 Cookie和Session

• Cookie用來保存HTTP的狀態(tài)信息抢埋。Cookie是服務器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)，它會在瀏覽器之后向同一服務器再次發(fā)起請求時被攜帶上督暂，用于告知服務端兩個請求是否來自同一瀏覽器揪垄。
• Session存儲在服務器端，使用Session維護用戶登陸狀態(tài)逻翁。
• 二者選擇：
  1.Cookie只能存儲ASCII碼字符串饥努，而Session則可以存儲任何類型的數(shù)據(jù)，因此在考慮數(shù)據(jù)復雜性時首選Session
  2.Cookie存儲在瀏覽器中八回，容易被惡意查看酷愧。如果非要將一些隱私數(shù)據(jù)存在Cookie中，可以將Cookie進行加密缠诅，然后在服務器進行解密溶浴。
  3.對于大型網站，如果用戶所有信息都存儲在Session中管引，那么開銷是很大的士败，因此不建議將所有的用戶信息都存儲到Session中。

5.5 HTTPS

• HTTP的安全性問題：
  1.使用明文通信褥伴，內容可能會被竊聽
  2.不驗證通信方的身份谅将，通信方的身份可能遭遇 偽裝
  3.無法驗證明文的完整性漾狼，明文可能會被篡改

• HTTPS（加密、認證戏自、完整性保護）：HTTP先和SSL通信邦投，再由SSL和TCP通信，也就是說HTTPS使用了隧道進行通信擅笔。

• 對稱密鑰加密：加密和解密都用同一密鑰，運算速度快屯援，無法安全地將密鑰傳輸給對方

• 非對稱密鑰密鑰：加密和解密使用不同的密鑰猛们，可以更安全地將公開密鑰傳輸給通信發(fā)送方，運算速度慢

• HTTPS采用混合的加密機制狞洋，使用非對稱密鑰加密用于傳輸對稱密鑰來保證傳輸過程的安全性弯淘，之后使用對稱密鑰加密進行通信來保證通信過程的效率。

• 缺點：速度慢吉懊、需要支付證書的昂貴費用

• HTTPS建立連接的過程：
  1.客戶端向服務端發(fā)送支持的加密協(xié)議及版本庐橙，SSL\TLS等
  2.服務端從中篩選適合的加密協(xié)議
  3.服務端向客戶端返回證書，證書中有公鑰
  4.客戶端使用根證書驗證證書合法性
  5.客戶端生成對稱密鑰借嗽，通過證書中的公鑰加密，發(fā)送到服務器端
  6.服務端使用私鑰解密，獲得對稱密鑰诚啃，使用對稱密鑰加密數(shù)據(jù)
  7.客戶端解密數(shù)據(jù)挪哄，SSL開始通信

5.6 HTTP/2.0

• HTTP/1.x的缺陷：
  1.客戶端需要多個連接才能實現(xiàn)并發(fā)和縮短延遲
  2.不會壓縮請求和響應首部，從而導致不必要的網絡流量
  3.不支持有效的資源優(yōu)先級惨寿，致使底層TCP連接利用率低下邦泄。
• 二進制分幀層
  HTTP/2.0將報文分成HEADERS幀和DATA幀，都是二進制格式的裂垦。在通信過程中顺囊，只會有一個TCP連接存在，它承載了任意數(shù)量的雙向數(shù)據(jù)流蕉拢。
• 服務端推送
  在客戶端請求一個資源時特碳，會把相關資源一起發(fā)送給客戶端，客戶端就不需要再次發(fā)送請求了企量。例如請求一個.html文件测萎，服務端會把相應的.css和.js文件一起發(fā)送。
• 首部壓縮
  使用霍夫曼編碼對首部字段進行壓縮届巩。HTTP/2.0要求客戶端和服務端同時維護和更新一個包含之前見過的首部字段表硅瞧，避免了重復傳輸。

5.7 GET和POST的區(qū)別：

• 作用
  GET用于獲取資源恕汇，POST用于傳輸實體主體
• 參數(shù)
  二者的請求都能使用額外的參數(shù)腕唧，但GET的參數(shù)是以查詢字符串出現(xiàn)在URL中或辖，而POST參數(shù)存儲在實體主體中。URL只支持ASCII碼枣接，所以如果存在中文等字符就需要先編碼颂暇。POST參數(shù)支持標準字符集
• 安全
  安全的HTTP方法不會改變服務器的狀態(tài)。因此GET方法是安全的但惶。而POST傳送的實體主體內容可能是用戶上傳的表單數(shù)據(jù)耳鸯，上傳成功之后，服務器可能把這個數(shù)據(jù)存儲到數(shù)據(jù)庫中膀曾，因此狀態(tài)發(fā)生了改變县爬。
  同時，PUT\DELETE也是不安全的添谊。
• 冪等性
  同樣的請求如果執(zhí)行一次和執(zhí)行多次的效果是一樣的财喳，服務器的狀態(tài)也是一樣的，那么就是具有冪等性的方法斩狱。所有安全的方法都是冪等的耳高。
• 緩存性
  GET是可緩存的，POST在多數(shù)情況下是不可緩存的所踊。

6.I/O模型

一個輸入操作泌枪，包括兩個階段，等待數(shù)據(jù)從網絡中到達污筷，從內核緩沖區(qū)復制到應用進程緩沖區(qū)

6.1 阻塞式I/O

第一階段和第二階段應用程序都被阻塞工闺，只有完成了第二階段才返回。但不影響其他進程的運行瓣蛀，所以對CPU的利用率高

6.2 NIO 非阻塞I/O

第一階段不阻塞陆蟆，需要不斷執(zhí)行系統(tǒng)調用來得知該階段是否完成，這種方式是輪詢（polling）惋增，第二階段阻塞叠殷，此模型需要CPU處理更多的系統(tǒng)調用，所以CPU利用率低

6.3 信號驅動I/O

應用進程使用sigaction進行系統(tǒng)調用诈皿，內核立即返回林束，第一屆都應用進程不阻塞，完成第一階段后向應用進程發(fā)送SIGIO信號稽亏，然后進行第二階段壶冒，該階段是阻塞的。該方式比NIO的CPU利用率更高截歉。

6.4 異步I/O

應用進程執(zhí)行aio_read系統(tǒng)調用會立即返回胖腾，應用進程可以繼續(xù)進行，不會阻塞，直到兩個階段都完成后咸作，才會向應用進程發(fā)送信號锨阿。也就是兩個階段都不會阻塞。

6.5 I/O復用

使用select或者poll等待數(shù)據(jù)记罚，并且可以等待多個套接字中任何一個變?yōu)榭勺x墅诡。某個套接字可讀時返回，再進行第二階段桐智。它的優(yōu)點是讓單個線程處理多個I/O末早，減少了線程創(chuàng)建和切換的開銷。但兩個階段都是阻塞的酵使。

• select
  調用select會一直阻塞直到有描述符的事件到達或者等待時間超過TIMEOUT荐吉。有三種類型的描述符，readset口渔、writeset、exceptset穿撮。select目前幾乎在所有平臺上都支持缺脉，缺點是單個進程能夠監(jiān)視描述符的數(shù)量存在最大限制，Linux上一般為1024悦穿。
• poll
  不同于select使用三個描述符來表示的方式攻礼，poll使用一個pollfd的指針實現(xiàn)。其并沒有最大數(shù)量的限制栗柒，poll返回后礁扮，需要輪詢pollfd來獲取就緒的描述符。
• select和poll的比較
  1.select會修改描述符瞬沦，poll不會
  2.select描述符類型使用數(shù)組實現(xiàn)太伊，單個進程能夠監(jiān)視描述符數(shù)量存在最大顯示，默認為1024逛钻，而poll沒有限制
  3.poll提供了更多事件類型僚焦，并且對描述符的重復利用上比select高
  4.二者每次調用都需要將全部描述符從應用進程緩存區(qū)復制到內核緩沖區(qū)。
  5.二者都需要用輪詢的方式獲取就緒的描述符
  6.幾乎所有系統(tǒng)都支持select曙痘，只有比較新的系統(tǒng)支持poll
• epoll
  epoll是select和poll的增強版本芳悲。相較于select和poll來說，epoll更加靈活边坤，沒有描述符限制名扛。epoll使用一個文件描述符管理多個描述符，將用戶關系的文件描述符事件存放到內核的一個事件表中茧痒，這樣在用戶空間和內核空間的copy只需一次肮韧。
  使用epoll_ctl()向內核注冊新的描述符或者是改變某個文描述符的狀態(tài)。已被注冊的描述符在內核中會被維護在一顆紅黑樹上，通過回調函數(shù)內核會將I/O準備好的描述符加入到一個鏈表中管理惹苗，進程使用epoll_wait()便可以得到事件完成的描述符殿较。
• epoll的工作模式
  1.LT：當epoll_wait檢測到描述符事件發(fā)生并將此事件通知應用程序，應用程序可以不立即處理該事件桩蓉。下次調用epoll_wait時淋纲，會再次響應應用程序并通知此事件。同時支持阻塞和非阻塞套接字
  2.ET：當epoll_wait檢測到描述符事件發(fā)生立即將此事件通知應用程序院究，應用程序必須立即處理該事件洽瞬。如果不處理，下次調用epoll_wait時业汰，不會再次響應應用程序并通知此事件伙窃。ET模式很大程度上減少了epoll事件被重復觸發(fā)的次數(shù)，因此效率比LT模式要高样漆。在該模式工作下为障，必須使用非阻塞套接字，以避免一個文件句柄的阻塞讀／寫操作把處理多個文件描述符的任務餓死放祟。
• 三者的應用場景
  1.select：select的timeout參數(shù)精度為1ns鳍怨，而其他的是1ms，因此select適用于實時性要求比較高的場景跪妥。
  2.poll：在實時性要求不高的場景鞋喇，且平臺支持，應使用poll而不是select
  3.epoll：運行在Linux平臺上眉撵，有大量的描述符需要同時輪詢侦香，并且這些連接最好是長連接。如果同時監(jiān)控小于1000纽疟，沒有必要使用epoll罐韩。如果需要監(jiān)控的描述符狀態(tài)變化多且短暫，也沒有必要用epoll仰挣。因為epoll中的所有描述符都存儲在內核中伴逸，造成每次需要對描述符的狀態(tài)改變都需要進行系統(tǒng)調用，頻繁的調用降低效率膘壶。

7. Socket函數(shù)

• socket()函數(shù)：用于創(chuàng)建一個socket描述符错蝴，用于標記一個唯一的socket
• bind()函數(shù)：把一個地址族的特定地址賦給socket
• listen()函數(shù)：服務端監(jiān)聽socket
• connect()函數(shù)：客戶端調用函數(shù)發(fā)出連接請求
• accept()函數(shù)：服務端監(jiān)聽到connect請求，調用accept()接收請求
• read()/write()函數(shù)：調用網絡I/O進行讀寫操作
• close()函數(shù)：關閉連接