問題：如果發送端發送的速度較快，接收端接收到資料後處理的速度較慢，而接收緩沖區的大小是固定的，就會丢失資料
, tcp協定通過''滑動視窗（slidingwindow）''機制解決這一問題。
1. 發送端發起連接配接，聲明最大段尺寸是1460，初始序号是0，視窗大小是4k，表示“我的接收緩沖區還有4k位元組空閑，你發的資料不要超過4k”。接收端應答連接配接請求，聲明最大段尺寸是1024，初始序号是8000，視窗大小是6k。發送端應答，三方握手結束。
2. 發送端發出段4-9，每個段帶1k的資料，發送端根據視窗大小知道接收端的緩沖區滿了，是以停止發送資料。
3. 接收端的應用程式提走2k資料，接收緩沖區又有了2k空閑，接收端發出段10，在應答已收到6k資料的同時聲明視窗大小為2k。
4. 接收端的應用程式又提走2k資料，接收緩沖區有4k空閑，接收端發出段11，重新聲明視窗大小為4k。
5. 發送端發出段12-13，每個段帶2k資料，段13同時還包含fin位。
6. 接收端應答接收到的2k資料（6145-8192），再加上fin位占一個序号8193，是以應答序号是8194，連接配接處于半關閉狀态，接收端同時聲明視窗大小為2k。
7. 接收端的應用程式提走2k資料，接收端重新聲明視窗大小為4k。
8. 接收端的應用程式提走剩下的2k資料，接收緩沖區全空，接收端重新聲明視窗大小為6k。
9. 接收端的應用程式在提走全部資料後，決定關閉連接配接，發出段17包含fin位，發送端應答，連接配接完全關閉。
發送端是一k一k地發送資料，而接收端的應用程式可以兩k兩k地提走資料，當然也有可能一次提走3k或6k資料，或者一次隻提走幾個位元組的資料，也就是說，應用程式所看到的資料是一個整體，或說是一個流（stream），在底層通訊中這些資料可能被拆成很多資料包來發送，但是一個資料包有多少位元組對應用程式是不可見的，是以tcp協定是面向流的協定。而udp是面向消息的協定，每個udp段都是一條消息，應用程式必須以消息為機關提取資料，不能一次提取任意位元組的資料，這一點和tcp是很不同的。