TCPストリームの最初に20バイトを送信した場合、2つの10バイトの断片として到着しないという保証があります。これは、TCPスタックがそのような小さなセグメントを送信しないためです。最小MTUサイズがあります。ただし、送信がストリームの途中にある場合、すべてのベットはオフになります。プロトコルスタックがセグメントを埋めて送信するために10バイトのデータを取得し、次の10バイトが別のセグメントに移動する可能性があります。
プロトコルスタックは、データをチャンクに分割し、キューに入れます。チャンクサイズはパスMTUに基づいています。送信操作を実行しても、まだキューに入れられたデータが保留中の場合、プロトコルスタックは通常、キューの末尾にあるセグメントを覗き、そのセグメントにデータを追加する余地があるかどうかを確認します。部屋は1バイトと小さい場合があるため、2バイトの送信でさえ2つに分割される可能性があります。
一方、データのセグメンテーションは、部分的な読み取りが可能であることを意味します。受信操作は、わずか1つのセグメントが到着したときに目覚め、データを取得する可能性があります。広く実装されているソケットAPIでは、受信呼び出しは20バイトを要求できますが、10で返される可能性があります。もちろん、20バイトが受信されるか、接続が切断されるまでブロックするバッファー層を構築できます。POSIXの世界では、そのAPIを標準のI / Oストリームにすることができfdopenます。ソケット記述子を使用してFILE *ストリームを取得し、freadそれを使用してバッファーを埋めることで、必要な数のread呼び出しで完全な要求を満たすことができます。
UDPデータグラムはデータをフレーム化します。送信呼び出しごとにデータグラムが生成されます（ただし、コーキングについては以下を参照してください）。反対側は完全なデータグラムを受け取ります（そして、ソケットAPIでは、それを保持するのに十分な大きさのバッファーを指定する必要があります。そうしないと、データグラムが切り捨てられます）。大きなデータグラムはIPフラグメンテーションによって断片化され、アプリケーションに対して透過的に再構築されます。フラグメントが欠落している場合、データグラム全体が失われます。そのような状況では、部分的なデータを読み取る方法はありません。
インターフェイスには、複数の操作で単一のデータグラムを指定できる拡張機能があります。Linuxでは、ソケットを「栓をする」ことができます（送信を防止）。書き込まれたデータは、コルク処理されている間、単一のユニットに組み立てられます。その後、ソケットが「アンコーク」されると、単一のデータグラムを送信できます。