一.三次握手
(1)客戶端要通知服務端，我要建立連接，發了一次請求
（2）服務端收到請求，要告訴客戶端，我收到你的請求了。發了一次ack
（3）客戶端收到信號後，要給服務端再發一次請求，不然服務端不知道客戶端有沒有收到它剛發的信息。
這樣之後，雙方都會建立資源，然後開始數據傳輸
可以看到下圖，請求百度的時候，前三次是建立聯繫，發送的數據length都是0,可以看到第二次ack是上一次請求seq+1
二.四次揮手
（1）當客戶端要斷開連接時，給服務端發信息
（2）服務端收到了，請求後，給客戶端，說我收到你的請求了，給客戶發了一個信息，ack，但這個時候還是可以發送數據的
（3）當服務端把數據傳完了，或者結束工作做完了，告訴客戶端，可以斷開連接了，發了一個信息給客戶端
（4）客戶端收到服務端的信息後，返回一個ack，就斷開連接了
三。網絡數據傳輸過程
比如要訪問百度
客戶端在路由表中找到路由器的Mac，路由器找到運營商的mac，運營商根據ip找到百度的mac，然後j進行傳輸
四。IO相關
（1）最原始的CS解決方案
服務器進行監聽，來一個客戶換進行連接，內核自己調用read方法，進行阻塞，這樣只有等第一個客戶端釋放，第二個客戶端才能進行
爲了解決上述read阻塞的問題
首先是內核不自己read了，每次來一個客戶端都是新啓動一個線程進行read，但這樣有個問題，就是客戶端多了，會創建很多線程，然後cpu的資源很多都浪費到切換線程上面。
內核發送了變化，文件描述符變成了非阻塞的。
爲了解決多線程創建與切換的問題，每來一個客戶端read不阻塞後，放入一個鏈表中，內核在去處理下一個客戶端，然後只需要一個線程去while鏈表中read的狀態就行，這種稱爲NIO
但是這種情況，有一個bi弊端，比如有10萬個客戶端，只有一個客戶端發了消息，但還是要遍歷鏈表，調用10萬次內核的read的方法。
爲了減少read方法的調用，使用了select來解決，現在客戶端不直接調用內核了，直接調用select，讓select把10萬個文件描述符拷貝到內核，內核遍歷問客戶端，得到需要調用的數量n，最後只用調用n次read方法。而不用調用10w次
但這個弊端是，客戶端調用一次select，select都需要大量拷貝文件描述符的到內核，然後內核要遍歷10w次。
epoll沒聽懂