TCPは（少なくとも概念的には)複数のタイマーを使って動作しているが、最も重要なタイマーは再送タイマー(retransmission timer)である。
セグメントを再送するタイマー
再送タイマー切れをRTO(Retransmission Time Out)と呼ぶ。セグメントが送信されると、再送タイマーもスタートする。タイマーが切れる前にそのセグメントの確認通知がやってくれば、タイマーは停止するが、そうでない場合はセグメントの再送が行われ、再びタイマーがスタートする。ここで、タイムアウトの間隔はどれくらいにすべきなのかという疑問が起こる。
データ・リンク・プロトコルの場合、遅延はマイクロ秒で測定され、かなり正確に予測できる。
TCPの確認通知がやって来る時間の確率密度は、図6-42(b)のようになる。宛先までの往復時間を決定するのは難しいし、それが与えられたとしても、タイムアウト時間を設定することもまた簡単ではない。
図6−42(b)のT1のようにタイムアウトを短くすると、不必要な再送を起こってしまい、インターネットを余分なパケットで溢れさせてしまう。しかし、T2のように長くしすぎると、パケット・ロスが起こった時再送遅延が大きなものになり、性能が悪化させる。
ウィンドウ幅を調べるタイマー
二つ目のタイマーは永続タイマー(persistence timer)と呼ばれ、以下で述べるデッドロックを回避するために用いられる。受信者がウインドウ幅０の確認通知を送り、送信者に待ってほしいと通知する。その後受信者はウインドウを更新するものの、その更新パケットがロスしたとする。すると、送信者、受信者とも相手が何かするのを待つことになる。永続タイマーが切れると、送信者は受信者に調査(probe)パケットを送る。受信者は調査パケットに対して、ウインドウ幅を返す。0のままであれば永続タイマーはもう一度設定され、もう一度今のサイクルを繰り返す。ウインドウ幅が０でなければ、再びデータを送ることができる。
コネクションを終了するタイマー
三つ目のタイマーは、一部の実装で利用されているキープアライブ・タイマー(keepalive timer)である。コネクションが
長い時間アイドルの時、キープアライブ・タイマーは切れ、相手がまだ存在するかを検査する。応答がない場合、コネクションは終了する。この機能はオーバーヘッドを増やし、一時的なネットワーク途切れに対して正常なコネクションを終了してしまう可能性があることから、議論の的になっている