TCP/IP協(xié)議
TCP/IP 是一個協(xié)議族硅蹦，也是按照層次劃分荣德。共四層：應(yīng)用層，傳輸層童芹，互連網(wǎng)絡(luò)層涮瞻，網(wǎng)絡(luò)接口層。
OSI網(wǎng)絡(luò)協(xié)議模型假褪，是一個參考模型署咽，而TCP/IP協(xié)議是事實上的標(biāo)準(zhǔn)。TCP/IP協(xié)議參考了OSI 模型嗜价，但是并沒有嚴(yán)格按照OSI規(guī)定的七層去劃分標(biāo)準(zhǔn)艇抠，而只劃分了四層，這樣會更簡單點久锥，更實用家淤。
TCP/IP協(xié)議和OSI模型也并不沖突，TCP/IP協(xié)議中的應(yīng)用層協(xié)議瑟由，就對應(yīng)于OSI中的應(yīng)用層絮重，表示層，會話層歹苦。
TCP/IP分層：
我們?nèi)粘ｉ_發(fā)中涉及到的網(wǎng)絡(luò)請求比如http請求和socket都是應(yīng)用層的青伤，基于tcp協(xié)議的。雖然我們沒有必要去探究整個協(xié)議細(xì)節(jié)問題殴瘦，但傳輸層tcp和udp的一些知識還是需要深入理解的狠角。
http協(xié)議
Http協(xié)議是建立在TCP協(xié)議基礎(chǔ)之上的，當(dāng)瀏覽器需要從服務(wù)器獲取網(wǎng)頁數(shù)據(jù)的時候蚪腋，會發(fā)出一次Http請求丰歌。Http會通過TCP建立起一個到服務(wù)器的連接通道，當(dāng)本次請求需要的數(shù)據(jù)完畢后屉凯，Http會立即將TCP連接斷開立帖，這個過程是很短的。所以Http連接是一種短連接悠砚，常見應(yīng)用場景是web請求晓勇，以及一些弱同步需求的場景，比如部分實時性要求不高的游戲。
TCP：傳輸控制協(xié)議
TCP是一種面向連接的绑咱、可靠的绰筛、基于字節(jié)流的傳輸層通信協(xié)議。
面向連接： 面向連接意味著使用tcp的應(yīng)用程序在傳輸數(shù)據(jù)前必須先建立連接描融，需要三次握手：
客戶端主動發(fā)起連接别智，發(fā)送syn包，server受到包后稼稿，同時帶ACK標(biāo)志和SYN標(biāo)志。表示對剛才客戶端SYN報文的回應(yīng)讳窟，seq表示序號让歼，雙方發(fā)出序號的包不一樣，但一定是遞增的丽啡。ACK=x+1表示谋右，已經(jīng)收到了x包，期望下一個需要為x+1的包补箍。client受到sever的syn報文改执，在回復(fù)一個ACK表示確認(rèn)。
為什么必須是三次握手坑雅？
信道不可靠辈挂，數(shù)據(jù)傳輸要可靠。三次通信是理論上的最小值(我理解的實際上需要雙方互相確認(rèn)裹粤，將SYN和ACK合并為一次了)终蒂。參照
可靠性：
1.確認(rèn)：
接收方收到報文就會確認(rèn)，發(fā)送方發(fā)送一段時間后沒有收到確認(rèn)就重傳遥诉。
實際開發(fā)中可以根據(jù)需要是否開啟延時確認(rèn)拇泣，響應(yīng)可能結(jié)合在一起，成一個響應(yīng)矮锈，減少協(xié)議開銷 霉翔。
優(yōu)點：減少了數(shù)據(jù)段的個數(shù)，提高了發(fā)送效率
缺點：過多的delay會拉長RTT
2.TCP重傳機制
TCP需要重傳機制來保證所有的數(shù)據(jù)包都可以到達苞笨。
1）超時重傳
超時重傳機制用來保證TCP傳輸?shù)目煽啃哉洹Ｃ看伟l(fā)送數(shù)據(jù)包時，發(fā)送的數(shù)據(jù)報都有seq號猫缭，接收端收到數(shù)據(jù)后葱弟，會回復(fù)ack進行確認(rèn)，表示某一seq號數(shù)據(jù)已經(jīng)收到猜丹。發(fā)送方在發(fā)送了某個seq包后芝加，等待一段時間，如果沒有收到對應(yīng)的ack回復(fù)，就會認(rèn)為報文丟失藏杖，會重傳這個數(shù)據(jù)包将塑。
- 快速重傳
TCP引入了一種叫Fast Retransmit 的算法，不以時間驅(qū)動蝌麸，而以數(shù)據(jù)驅(qū)動重傳点寥。也就是說，如果来吩，包沒有連續(xù)到達敢辩，就ack最后那個可能被丟了的包，如果發(fā)送方連續(xù)收到3次相同的ack弟疆，就重傳戚长。Fast Retransmit的好處是不用等timeout了再重傳。
另外一種更好的方式叫：Selective Acknowledgment (SACK)（參看RFC 2018）怠苔，這種方式需要在TCP頭里加一個SACK的東西同廉，ACK還是Fast Retransmit的ACK，SACK則是匯報收到的數(shù)據(jù)碎版柑司。
3.流量控制
TCP header中有一個Window Size字段迫肖，它其實是指接收端的窗口，即接收窗口攒驰，用來告知發(fā)送端自己所能接收的數(shù)據(jù)量蟆湖，從而達到一部分流控的目的。三次握手的過程中雙發(fā)發(fā)送的數(shù)據(jù)包里就帶了各自的winsize玻粪，發(fā)送端的發(fā)送窗口是基于接收端的接收窗口來計算的帐姻。
（1）已經(jīng)發(fā)送并且對端確認(rèn)（Sent/ACKed）---------------發(fā)送窗外 緩沖區(qū)外
（2）已經(jīng)發(fā)送但未收到確認(rèn)數(shù)據(jù)（Sent/UnACKed）-------發(fā)送窗內(nèi) 緩沖區(qū)內(nèi)?
（3）允許發(fā)送但尚未防的數(shù)據(jù)?（Unsent/Inside）-----------發(fā)送窗內(nèi) 緩沖區(qū)內(nèi)?
（4）未發(fā)送暫不允許（Unsent/Outside）-------------------發(fā)送窗外 緩沖區(qū)內(nèi)?
TCP窗口就是這樣逐漸滑動，發(fā)送新的數(shù)據(jù)奶段，滑動的依據(jù)就是發(fā)送數(shù)據(jù)已經(jīng)收到ACK饥瓷，確認(rèn)對端收到，才能繼續(xù)窗口滑動發(fā)送新的數(shù)據(jù)痹籍∧孛可以看到窗口大小對于吞吐量有著重要影響，同時ACK響應(yīng)與系統(tǒng)延時又密切相關(guān)蹲缠。
擁塞控制下篇在寫棺克，好難寫。
