1448位元組是實際場景下，單個tcp包的實際運載能力。也就是說，實際場景下，上層呼叫send（1000kb），下層會把這1000kb封裝成多個tcp包進行傳送。單個tcp包每次打包1448位元組的資料進行傳送。
詳細的tcp在傳輸情景wireshark截圖如圖1
圖1每個tcp包在理論上應該能打包更多資料才對，但是實際場景下tcp傳輸為什麼會以這個1448作為打包單位呢？
這個實際tcp單包傳輸1448位元組資料的根源在於「乙太網ethernet最大的資料幀是1518位元組」。
乙太網ethernet最大的資料幀是1518位元組。乙太網幀的幀頭14位元組和幀尾crc校驗4位元組（共佔18位元組），剩下承載上層協議的地方也就是data域最大就只剩1500位元組. 這個值我們就把它稱之為mtu。
我們來看看linux上mtu預設值，查證一下，如圖2
圖2這個mtu值可以修改，但是現在大部分計算機網路都被乙太網承載，所以修改這個值沒有什麼實際意義。
mss就是tcp資料報每次能夠傳輸的最大量。為了達到最佳的傳輸效能，tcp協議在建立連線的時候通常要協商雙方的mss值，這個值tcp協議在實現的
時候往往用mtu值代替（需要減去ip資料報包頭的大小20bytes和tcp資料段的包頭20bytes）所以往往mss為1460（如圖1中紅色方框所示的syn包中的mss值）。通訊雙方會根據雙方提供的mss值得最小值確定為這次連線的最大mss值。
mss為1460是由1500-20（ip頭）-20（tcp頭）計算出的。
實際場景下，tcp包頭中會帶有12位元組的選項----時間戳。
這樣，單個tcp包實際傳輸的最大量就縮減為1448位元組。1448=1500-20（ip頭）-32（20位元組tcp頭和12位元組tcp選項時間戳）
「每個tcp包在理論上應該能打包更多資料才對，但是實際場景下tcp傳輸為什麼會以這個1448作為打包單位呢？」
理論上，單個tcp包能打包的資料量遠遠多於1448位元組，現在為了適應mtu，只要在乙太網上跑tcp，系統就預設最大以1448位元組打包tcp。
假如我們用更大的資料量來打包會有什麼結果呢？
答案是降低了傳輸效率。
超過mtu的大包反而降低效率的原因如下：
ip層非常關心mtu，因為ip層會根據mtu來決定是否把上層傳下來的資料進行分片。就像一條運輸線路的承載能力是有限的，碰到大東西要運輸，只能把大東西拆開成為散件，分開運輸，到達目的地之後還必須能再次組裝起來。
當兩台遠端pc互聯的時候，它們的資料需要穿過很多的路由器和各種各樣的網路媒介才能到達對端，網路中不同媒介的mtu各不相同，就好比一長段的水管，由不同粗細的水管組成（mtu不同 :)）通過這段水管最大水量就要由中間最細的水管決定。
對於網路層的上層協議而言（我們以tcp/ip協議族為例）它們對水管粗細不在意它們認為這個是網路層的事情。網路層ip協議會檢查每個從上層協議下來的資料報的大小，並根據本機mtu的大小決定是否作「分片」處理。分片最大的壞處就是降低了傳輸效能，本來一次可以搞定的事情，分成多次搞定，所以在網路層更高一層（就是傳輸層）的實現中往往會對此加以注意！
這個就是在乙太網上，tcp不發大包，反而傳送1448小包的原因。只要這個值tcp才能對鏈路進行效能最高的利用。
Memcache可寫的最大位元組數
原貼 http www.ourlinux.net faq memcache can write max bytes written by bixuan on 2008年06月20號 09 44 做了一下測試，memcache的key value的總最大可寫位元組數是 1048521 bytes te...
關於網路傳輸中最大傳輸報文MTU的思考
一般tcp的書都會說在網路傳輸中最大傳輸報文mtu一般為1500位元組，但是在一次區域網的測試卻發現了如下問題 首先從後兩張我們可以確定c s兩端都是相互確認了mss為1460個位元組的，但是為啥第一張圖卻出了乙個2962位元組的包了呢，這明顯這是跟書上觀點相違背的。經過一段痛苦的查究下，發現原來網...
面向報文（UDP）和面向位元組流（TCP）的區別
面向報文 udp 和面向位元組流 tcp 的區別 面向報文的傳輸方式是應用層交給udp多長的報文，udp就照樣傳送，即一次傳送乙個報文。因此，應用程式必須選擇合適大小的報文。若報文太長，則ip層需要分片，降低效率。若太短，會是ip太小。udp對應用層交下來的報文，既不合併，也不拆分，而是保留這些報文...