Linuxのどのプロセスが実際に受信側のネットワーク層から情報を取得し、すべてのTCP関連ロジック（TCPレベルのエラーチェック、セグメント承認など）を適用し、それを受信バッファに入れるかを知りたいです。受信側が接続を待っていますか？
一方、ホストアプリケーションがソケットに送信した情報を受信して処理し、ネットワーク層に送信するプロセスは何ですか？
たぶん私はプロセスを正しく理解していないかもしれません。助けてください。
答え1
あなたの質問は混乱しています。 TCP / IPを説明するためにOSIモデルに基づいています。しかし、これは不可能です。 TCP / IPはOSIの前にリリースされ、そのモデルに固執する意図はありませんでした。 HTTP / 2をサポートするブラウザを使用してこのページにアクセスすると、ネットワーク自体のWAN最適化は言うまでもなく、少なくとも3つの異なるスタックレイヤで圧縮が処理される少なくとも4つの別々のセッションレイヤがあります。
LinuxでTCPを担当するプロセスは何ですか？
TCPはカーネルで発生します。ユーザープロセスにはありません。したがって、参照フレームに応じてすべてまたはまったくありません。
答え2
コードに関しては、実際にはカーネル空間に存在するコードであり、NICドライバで上向きにTCP実装を処理します。 Linuxカーネルはネットワークハードウェアを理解し、それをリンクアダプタセットに抽象化します。その後、TCP / UDP / IPスタックはこれらの「リンク」デバイスを認識し、それをソケットなどのLinux / Unixレベルの概念に抽象化します。
プロセスはカーネルへのシステムコールを介してこの機能にアクセスします。 Linuxのプロセス概念はカーネルから分離または制限されていますが、技術的にはすべてのプロセスはシステムコールを介してこの機能にアクセスできます。
これは、NICからデータが受信されるとカーネルがTCPを処理することを意味します。アプリケーションがバッファからデータを受信すると、プロセスはカーネルスペース/メモリから始まるsyscallを介してゲート方式でTCPを処理します。
Linuxはプリエンプティブなので、カーネル空間への呼び出しも、少なくともカーネルがプロセス共有時間を追跡する方法の一部であるため、技術的にTCPを各プロセスの一部として考えることができます。ただし、メモリ空間（ユーザ空間アプリケーション）処理に属するコードのみを考慮すると、カーネルだけがTCPを処理します。
Linux/Unix は、アプリケーションのコンパイル時にリンクされるライブラリーとして TCP/IP を抽象化するいくつかのソケット機能を統合し、そのメモリー・スペースに常駐します。たとえば、IPアドレスを表すために使用されるメモリ構造です。