FIN -> FIN/ACK -> ACK という TCP の幻想 - kawasin73のブログ
掴んで離さぬコネクション。どうも、かわしんです。しがみつかずに適切なタイミングで離しましょう。 この１週間で RFC を読みながら TCP/IP プロトコルスタックを自作した 1 のですが、その時にコネクションの終了処理でハマったので後学のために書き残しておきます。 一言でまとめると FIN -> FIN/ACK -> ACK は間違っていて、正しくは FIN/ACK -> FIN/ACK -> ACK であったという話です。 ちなみに、僕が自作した TCP/IP プロトコルスタックはこれです。 github.com 現象 それは TCP のリスナーと close 処理が出来上がってコネクション管理のテストをしていた時のことでした。 自作 TCP スタックでポートを Listen して Accept したらすぐにサーバ側からコネクションを切断するというテストコードを書いて実行し、Linux
Geekなぺーじ : TCP vs RTP：何故RTPが必要なのか？
インターネットを流れるトラフィックのほとんどがTCP(Trasmission Control Protocol)によるものです。 TCPは、全てのデータが正しく相手に伝わることを保証するため品質の高いデータ通信が実現できます。 また、どのパケットが受け取れなくて、どれが受け取れたかなどをわざわざ考えなくても良いので、プログラムを書くのも簡単です。 では、何故、わざわざRTPというものが必要だったのでしょうか？ ここでは、まず最初に何故RTPはTCPではなく、UDPの上に存在しているのかを説明したいと思います。 （もちろん、TCPの上に作ることはRTPの規約上は可能ですが、現実的にはUDPの上でしか実装がないと思います。） その後、何故、UDPの上に共通のRTPというものを構築したのかを説明したいと思います。 RTPは、名前にもある通り、「リアルタイム」なデータを転送するためのプロトコルです
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
