Flow Control pada TCP

Sebagian besar diskusi tentang Sliding Window pada TCP sama dengan yang dibahas pada sliding window, perbedaan utamanya hanya pada bagian ini kita mempertimbangkan fakta bahwa proses pada aplikasi pengirim adalah memenuhi buffer dan penerima adalah mengosongkan buffer mereka masing-masing. Pembahasan mencakup fakta bahwa data yang tiba dari sebuah node upstream adalah memenuhi buffer pengirim dan data yang sedang dikirim pada node downstream adalah mengosongkan buffer penerima.
Yang harus anda pastikan untuk mengerti hal tersebut sebelum melanjutkan karena sekarang ketika masuk pada bagian dimana dua algoritma berbeda secara lebih signifikan. Pada bab berikutnya, kita memperkenalkan kembali fakta bahwa kedua buffer mempunyai ukuran yang terbatas, dengan notasi MaxSendBuffer dan MaxRcvBuffer, walaupun kita tidak terlalu memperhatikan detail bagaimana keduanya diimplementasikan. Dengan kata lain, kita hanya tertarik pada jumlah byte yang sedang dibuffer, bukan dimana sebenarnya kedua byte tersebut disimpan.
Perlu diingat bahwa pada protocol sliding window,  ukuran window disesuaikan dengan jumlah data yang bisa dikirim tanpa harus menunggu ACK dari receiver. Oleh karena itu, receiver/penerima menekan pengirim dengan menawarkan sebuah window yang tidak lebih besar dari jumlah data yang bisa disimpan. Amati bahwa TCP pada sisi penerima harus menjaga kondisi bahwa

LastByteRcvd−LastByteRead ≤ MaxRcvBuffer

untuk menghindari terlalu membanjiri buffer penerima. Oleh karena itu, penerima menawarkan sebuah ukuran window

AdvertisedWindow = MaxRcvBuffer−((NextByteExpected−1)−LastByteRead)

yang mana mewakili jumlah ruang kosong yang tersisa dalam buffernya. Ketika data tiba, penerima meng-ACK selama semua byte yang mendahului sudah juga sudah tiba. Sebagai tambahan, LastByteRcvd bergerak ke kana (nilainya naik), yang berarti bahwa window yang ditawarkan(Advertised Window) berpotensi untuk berkurang. Apakah ukuran window jadi berkurang atau tidak tergantung seberapa cepat proses aplikasi local mengkonsumsi data. Jika proses loka sedang membaca data seketika setelah datang yang menyebabkan LastByteRead selalu naik bersamaan dengan laju LastByteRcvd, maka ukuran window yang ditawarkan akan selalu terbuka(open, AdvertisedWindow = MaxRcvBuffer). Namun, jika proses yang menerima tertinggal dibelakang, mungkin karena sedang melakukan operasi yang berat pada setiap byte data yang dibaca, maka ukuran window yang ditawarkan menjadi lebih kecil setiak kali segmen tiba, sampai pada akhirnya ukurannya menjadi 0.

TCP pada sisi pengirim harus menyesuaikan ukuran window yang ditawarkan, yang didapat dari penerima. Hal ini berarti bahwa pada suatu waktu tertentu, pengirim harus menjamin bahwa

LastByteSent−LastByteAcked ≤ AdvertisedWindow

menurut sisi yang lain, pengirim menghitung sebuah ukuran window yang membatasi seberapa banyak data yang bisa dikirim:

EffectiveWindow = AdvertisedWindow−(LastByteSent−LastByteAcked)

Secara jelas, EffectiveWindow harus lebih besar dari pada 0 sebelum sumber bisa mengirim lebih banyak data. Sehingga dimungkinkan, oleh karena itu, sebuah segmen tiba yang meng-ACK x buah byte, yang nantinya memungkinkan sender untuk meningkatkan LastByteAcked sebanyak x, namun karena proses penerima tidak membaca data apapun, ukuran window yang ditawarkan sekarang x byte lebih kecil dari sebelumnya. Pada situasi ini, pengirim akan bisa mengosongkan ruang buffer, namun bukan untuk mengirim data lagi.
Ketika semua hal ini terjadi, pada sisi penerima harus menjamin bahwa proses aplikasi local tidak membanjiri buffer pengirim, sehingga

LastByteWritten−LastByteAcked ≤ MaxSendBuffer

Jika proses pengirim mencoba menulis y byte pada TCP, namun

(LastByteWritten−LastByteAcked)+y > MaxSendBuffer

Maka TCP mem-blok proses pengirim dan tidak membiarkan proses pengirim untuk meng-hasilkan lebih banyak data.
Sekarang dimungkinkan untuk mengerti bagaimana sebuah proses yang lambat dalam menerima pada akhirnya menghentikan proses pengiriman yang cepat. Pertama, buffer penerima menjadi penuh, yang mana window yang ditawarkan menjadi 0. Kondisi ukuran window yang ditawarkan 0 berarti pada sisi pengirim tidak bisa mengirimkan data, walaupun data yang sebelumnya berhasil terkirim telah sukses di-ACK. Terakhir, tidak berhasil mengirim data apapun berarti buffer pengirim juga penuh, yang mana membuat TCP menghentikan proses pengiriman. Sesegera setelah proses pengiriman mulai melakukan pembacaan data lagi, sisi pengirim pada TCP bisa window kembali, yang mana memungkinkan TCP pada sisi pengirim mengirimkan data keluar dari buffernya. Ketika data ini pada akhirnya di-ACK, LastByteAcked dinaikkan nilainya, ruang buffer yang menjaga data yang diACK ini menjadi bebas, dan proses aplikasi pengiriman menjadi tidak diblok dan memperbolehkan untuk melanjutkan pengiriman.
Terdapat satu detail tersisa yang harus dipecahkan, bagaimana sisi pengirim tahu bahwa ukuran window yang ditawarkan tidak lagi 0? Seperti yang disebutkan di atas, TCP selalu mengirim sebuah segmen sebagai jawaban dari sebuah segmen data yang diterima, dan jawaban(response) ini berisi nilai terbaru dari AdvertisedWindow field untuk ACK, bahkan jika nilai ini tidak berubah sejak terakhir kali data terkirim. Permasalahannya adalah, ketika sisi penerima mempunyai ukuran window yang ditawarkan bernilai 0, dan pengirim tidak diizinkan untuk mengirim data lagi, yang mana berarti tidak ada cara  untuk mengetahui bahwa ukuran window yang ditawarkan tidak lagi 0 pada beberapa waktu kedepan. TCP pada sisi penerima tidak secara tiba-tiba mengirim segmen nondata; penerima hanya mengirimkan segmen nondata(ACK) sebagai jawaban pada sebuah segmen data yang tiba.
TCP menghadapi permasalahan tersebut sebagai berikut. Setiap kali sisi lain menawarkan sebuah ukuran window 0, sisi pengirim terus menerus mengirimkan sebuah segmen dengan ukuran 1 byte secara sering dan terus menerus. Pengirim tahu bahwa data ini mungkin tidak akan diterima, namun pengirim tetap mencoba, karena setiap satu byte segmen memacu sebuah respons yang berisi ukuran window yang ditawarkan saat ini. Pada akhirnya, satu dari 1-byte pengurkur ini memacu respons yang melaporkan sebuah ukuran window yang ditawarkan berukuran tidak 0.