Wird die Transportschicht (z. B. UDP, TCP) normalerweise vom Betriebssystem verwaltet? [geschlossen]

Ich bin wirklich neu im Networking und habe Mühe, das zu verstehen.

Ich weiß, dass die Transportschicht in der Internet Protocol Suite (zumindest die UDP- und TCP-Protokolle) die Quelle und das Ziel enthält Portnummern und das gibt es ein Anwendung, die auf einem Computer ausgeführt wird, der dieser Portnummer zugeordnet ist.

Wenn also ein Frame aus dem Internet auf dem Computer ankommt, führt das Betriebssystem die Funktionen der Transportschicht aus (garantierte Zustellung usw.) und leitet die Nutzlast dann an die Anwendung weiter, die diese ausführt Eingetragen sich mit dem Betriebssystem unter der im Transport Layer des Frames angegebenen Zielportnummer?

Kann jemand etwas detaillierter erklären, wie das Betriebssystem dies tut? (z. B. Ist es ein Teil des in das Betriebssystem eingebauten Kernels? Wie erhält das Betriebssystem den Zugriff auf den Frame? usw.)

Kurze Antwort auf die Frage: Die Hardware / Firmware der Netzwerkschnittstelle und das Betriebssystem erledigen all das.

Genauer gesagt sind einige Fahrer beteiligt. Das Gerät deckt normalerweise die OSI-Schichten 1 (physikalisch) und 2 (Datenverbindung) selbst ab, d. H. Die Übersetzung zwischen physikalischen Signalen (elektrisch, Funk) und Bits und deren Gruppierung zu Rahmen wird von der Hardware / Firmware durchgeführt. Der Gerätetreiber steuert die entsprechenden Funktionen. Die Schichten 3 (Netzwerk) und 4 (Transport) werden vom Betriebssystem abgedeckt, obwohl privilegierte Userland-Prozesse möglicherweise Zugriff auf die Daten erhalten.

Wie kommt das Betriebssystem an den Frame?

Wenn der Netzwerkschnittstelle ein Frame zur Verfügung steht, wird ein Interrupt ausgelöst, sodass der Kernel ihn aus dem entsprechenden E / A-Speicherbereich auslesen kann.

Die Frame-Header-Daten geben an, was mit dem Frame geschehen soll. Wenn der Kernel (genauer: der Netzwerktreiber) den Typ der Nutzlast (z. B. IPv4 oder IPv6) kennt, wird das Paket (nach Entfernen der Header und Trailer der Schicht 2) an den entsprechenden Netzwerktreiber weitergeleitet.

Es behandelt alle Besonderheiten des Netzwerkschichtprotokolls wie Fragmentierung und Zusammenbau, Prüfsummenberechnung und -verifizierung usw. sowie alle netzwerkschichtspezifischen Aufgaben wie Routing und Paketfilterung. Abhängig von der Nutzlast (TCP, UDP, ICMP, ICMPv6, GRE, SCTP, DCCP usw.) wird das Paket weiter an den entsprechenden Transportschichtentreiber weitergeleitet. Es kümmert sich um alle Transportschicht-spezifischen Dinge. Für verbindungsorientierte Protokolle wie TCP bedeutet dies beispielsweise, den Verbindungsstatus zu verfolgen, die Warteschlangen zu verwalten und die Buchhaltung zu übernehmen. Eine andere Sache ist die Überlastungskontrolle.

Sobald ein Paket diese Schicht passiert hat, wird es weiter nach oben weitergeleitet (erneut nach dem Entfernen des Transportschicht-Headers), diesmal jedoch an den Userland-Prozess. Der Userland-Prozess sieht so gut wie nichts von der Verarbeitung auf niedrigerer Ebene.

Jetzt ist es möglich, auf Rohdaten wie Frames aus dem Userland zuzugreifen und diese zu verarbeiten. Dies können Sie mit Software wie libpcap tun. All dies im Kernel zu tun ist jedoch effizienter.

Sehen Wo arbeitet die Transportschicht? auf Stapelüberlauf

Antwort von EJP:

Ist es Teil des Betriebssystems?

Ja.

Läuft es in einem eigenen Prozess oder Thread?

Nein, es läuft als Teil des Betriebssystems.

Wie werden Informationen an andere Anwendungen weitergegeben?

Über Systemaufrufe, z. die Berkeley Sockets API, WinSock usw.

oder runter auf andere schichten?

Über interne Kernel-APIs.

Siehe auch andere Antworten.