Netzwerk-Programmiermodelle und I/O Optimierungen für Unix Betriebssyteme

Transkript

1 Netzwerk-Programmiermodelle und I/O Optimierungen für Unix Betriebssyteme Aktuelle Themen der Informatik WS 2006/2007 Prof. Dr. Friedbert Kaspar Furtwangen, 14. November 2006 Hagen Paul Pfeifer Florian Westphal Hochschule Furtwangen Studiengang Computer Networking Fakultät Informatik

2 Inhaltsverzeichnis 1 Client/Server Programmiermodelle Ein Prozess pro Client Ein Thread pro Client Ein Prozess/Thread, mehrere Clients Readiness Notification mit select select: Einschränkungen und Probleme Readiness Notification mit poll Vorteile gegenüber select poll: Einschränkungen und Probleme Das alternative poll-interface /dev/poll Linux 2.6: epoll Readiness Notification mit epoll Change Notification mit epoll BSD: kqueue kevent libevent Effizientere TCP-Behandlung Zero-Copy Speicher Abbildungen - Die Funkion mmap Sendfile TCP-Cork writev Splice und Tee splice Tee Literaturverzeichnis 23 2

3 Die vorliegende Arbeit ist die im Rahmen des Seminars Aktuelle Themen der Informatik im Wintersemester 2006/2007 angefertigte Ausarbeitung zum Thema: Skalierbare Unix Netzwerkprogrammierung Die Ausarbeitung wurde mit Hilfe von Subversion und L A TEX 2ε erstellt.

4 1 Client/Server Programmiermodelle 1.1 Ein Prozess pro Client Der klassische Unix-Ansatz verwendet einen neuen Prozess pro Client. Der Server-Task blockiert im accept() Syscall, beim Eintreffen einer Verbindung wird ein neuer Prozess erzeugt, der die Verbindung bearbeitet. Dieser Ansatz hat vorallem den Vorteil, das Fehler durchaus mit einer Beendigung des Prozesses behandelt werden können der Server-Prozess läuft unabhängig von seinen Kindprozessen. Die Behandlung von Timeouts ist ebenfalls einfach: Aufruf von alarm(timeout), falls danach Daten empfangen werden, kann der Timer durch erneutes aufrufen von alarm aufgehoben (und neu gesetzt) werden. Das Programm inetd nimmt dem Programmierer sogar einen großteil der Arbeit ab, da inetd die Client Verbindung aktzeptiert, und danach ein Programm in einem eigenen Kontext startet. Das Design hat aber auch Nachteile: Bei Last-spitzen wird die Erzeugung neuer Prozesse zum Flaschenhals. Zwar können bereits im Vorfeld neue Prozesse erzeugt werden (sog. preforking) dies ist aber mehr ein entlastender Notbehelf statt eine wirkliche Lösung (wenn zehn Kindprozesse vorgehalten werden, aber mehr als 10 Clients gleichzeitig verbinden, muss eben der Rest warten). Falls generell sehr viele Clients gleichzeitig zu erwarten sind, so hängt die Gesamtperformance sehr vom Scheduler ab 1. Ein solches Design ist eine gute Wahl, wenn nur wenige Clients gleichzeitig zu erwarten sind oder die Verbindungen nur von sehr kurzer Dauer sind. 1.2 Ein Thread pro Client Dies ist dem fork- basierten Ansatz ähnlich; jedoch ist die Erzeugung von Threads schneller, besonders unter Linux: pthread_create verbraucht nur etwa ein Sechzehntel der CPU-Zyklen 2. 1 Linux 2.4: O(n), Linux 2.6: O(1) 2 Linux 2.4: ca. ein Drittel 4

5 KAPITEL 1. CLIENT/SERVER PROGRAMMIERMODELLE CPU - Zyklen Min. Max. Durchschnitt fork pthread_create Tabelle 1.1: CPU-Zyklenzeit fork vs. pthread create. Linux , Native Posix Threads, CPU: Athlon XP, MHz Nachteilig ist zusätzlicher Synchronisationsaufwand, falls geteilte Daten manipuliert werden Ein Prozess/Thread, mehrere Clients Typischerweise handelt es sich um einen Event Loop, der alle vorhandenen Netzwerk- Sockets überwacht und abhängig von den Anfragen/Ereignisse, welche auf den Sockets eingehen Aktionen durchführt. Ein solches Design ist fast unabhängig vom Scheduler, erfodert aber einen deutlich höheren Design und Programmieraufwand, da keine einzige Operation blockieren darf. Dies ist umso Problematischer, da viele Häufig verwendeten Programmierschnittstellen in dieser Hinsicht ungeeignet sind z.b. blockiert gethostbyaddr() solange, bis eine Antwort eintrifft in dieser Zeit ist das Gesamte Programm blockiert! Sogar jeder Dateizugriff kann blockieren 4 für Platten-I/O muss generell auf asynchrone Schnittstellen (aio_read, aio_write... ) ausgewichen werden (alternativ können derartige Aufgaben auch in einen eigenen Thread ausgelagert werden). Da sich jede Verbindung aus sicht des Applikationsprotokolls in einem anderen Zustand befindet (oder zumindest kann), muss dieser auch seperat für jeden Client mitgeführt werden. Zur Ereignisüberwachung stehen zwei Designs zur Auswahl: 1. Level-Triggered: ( Readiness Notification ) 2. Edge-Triggered: ( Change Notification ) Bei einem Level-Triggered-Ansatz werden ein oder mehrere Dateideskriptoren (sockets) beim Kern registriert. Der Kern meldet die Deskriptoren, solange sie sich in diesem Zustand befinden. Beispiel: Ereignis: Von Socket 42 kann gesessen werden Applikation liest einen Teil der Eingetroffenen Daten Ereignis wird dann erneut gemeldet 3 Dies gilt auch für Prozesse, falls diese gemeinsam auf mit IPC-Mitteln geteilten Ressourcen operieren 4 Das Attribut O NONBLOCK ist hier bedeutungslos 5

6 KAPITEL 1. CLIENT/SERVER PROGRAMMIERMODELLE Die bekanntesten Vertreter dieses Designs ist das select()-interface. Im Gegensatz werden bei einem Edge-Triggered-Verfahren nur Änderungen des Zustandes gemeldet. Beispiel: Ereignis: Von Socket 42 kann gelesen werden Applikation liest einen Teil der Eingetroffenen Daten Ereignis wird erst dann erneut gemeldet, wenn die Applikation alle Daten gelesen hat (genauer: read meldet EAGAIN). 1.4 Readiness Notification mit select select ist der am weitesten Verbreitete und auch älteste Vertreter der Unix Multiplexing- Mechanismen 5. int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); Der Programmierer deklariert fd_sets 6, für die zu überwachenden Sockets. Anschlïesend werden mit dem FD_SET()-makro Sockets zu diesem Set hinzugefügt. Danach können diese Sets an select() übergeben werden. Ein Aufruf von select kehrt zurück, wenn Das Timeout abläuft (der Wert NULL als Timeout verhindert dies) Mindestens einer der in einem Set befindlichen sockets ein Ereignis aufweist. In diesem Fall weist der Rückgabewert die Anzahl an Ereignisbehafteten Deskriptoren aus. Nachdem select Ereignisse meldet, kann nun mit dem FD_ISSET Makro getestet werden, ob ein bestimmter Deskriptor für die gewünschte Operation verfügbar ist (Deskriptoren, die nicht verfügbar sind, werden von select aus dem set entfernt!). Beispiel: fd_set readers, writers; /* sets initialisieren */ FD_ZERO(&readers); FD_ZERO(&writers); 5 seit 4.2 BSD (1983) 6 Meist eine Struktur, welche ein Array aus longs enthält 6

7 KAPITEL 1. CLIENT/SERVER PROGRAMMIERMODELLE FD_SET(sock, &readers); /* melde wenn socket daten enth"alt */ FD_SET(sock, &readers); /* melde wenn Schreiboperation auf socket Moeglich ist */ fd_set readers_tmp = readers; fd_set writers_tmp = writers; int ret = select(select_maxfd + 1, &readers_tmp, &writers_tmp, NULL, NULL); if (ret < 0) /* Fehlerbehandlung */ for (i=0; i <= select_maxfd; i++) { if (FD_ISSET(i, &readers_tmp)) lese_daten(i); if (FD_ISSET(i, &writers_tmp)) schreibe_daten(i); Da select Grundsätzlich Level-Triggered ist, werden Ereignisse auch dann erneut gemeldet, wenn lese_daten() nicht alle verfügbaren Daten aus dem Socket-Empfangspuffer liest select: Einschränkungen und Probleme Die von select Verwendeten fd_sets sind gewöhnlich mittels Bitvektoren implementiert und müssen jeweils linear abgesucht werden. Der Erste Parameter zur Funktion gibt das Höchste zu Untersuchende Bit an und entspricht daher dem höchsten Deskriptor plus eins. Applikationen, die select für mehrere Sockets einsetzen, führen daher für gewöhnlich die höchste aktuelle Deskriptornummer in einer Variable mit. Wird der höchste Deskriptor geschlossen, muss der nächstkleinere neu ermittelt werden. Dies ist zwar vergleichsweise einfach lösbar, stellt aber dennoch einen zusätzlichen Aufwand dar. Die Verwendung von Bitvektoren ist in anderer Hinsicht von viel Größerem Nachteil: Sie sind in ihrer Größe beschränkt: So können in fd_sets nur Deskriptoren verwaltet werden, die kleiner sind als die Konstante FD_SETSIZE. 1.5 Readiness Notification mit poll poll ist eine 1986 in SystemV Release 3 eingeführter Schnittstelle zur Ereignisüberwachung von Dateideskriptoren 7. Im Gegensatz zu select gibt es keine direkte Beschränkung der maximal verwenbaren Deskriptornummer: int poll(struct pollfd *fds, nfds_t nfds, int timeout); 7 select stand 1986 in SystemV nicht zur Verfügung 7

8 KAPITEL 1. CLIENT/SERVER PROGRAMMIERMODELLE struct pollfd { int fd; /* file descriptor */ short events; /* requested events */ short revents; /* returned events */ ; Abbildung 1.1: pollfd - Strukur poll erhält einen Zeiger auf ein Array aus pollfd-strukturen (siehe 1.1, in diesen werden die jeweiligen Sockets im fd-feld mit den jeweils gewünschten Ereignissen (events)eingetragen. Wie select kehrt poll dann zurück, wenn mindestens ein Deskriptor Ereignisse hatte, in diesem Fall kann der entsprechende Zustand aus revents-feld gelesen werden. Der Timeout- Parameter (in Millisekunden) spezifiziert die maximale Wartezeit, bei negativen Werten wird solange gewartet, bis Ereignisse auftreten. Beispiel: struct pollfds[2]; pollfds[0].fd = 0; pollfds[1].fd = 1; pollfds[0].events = POLLIN; /* melde wenn auf fd 0 Daten verfuegbar sind */ pollfds[1].events = POLLOUT; /* melde wenn Schreiboperation auf fd 1 moeglich ist * int ret = poll(pollfds, 2, 0); if (ret < 0) /* Fehlerbehandlung */ for (i=0; i < 2; i++) { if (pollfds[i].revents & POLLIN) lese_daten(i); if (pollfds[i].revents & POLLOUT) schreibe_daten(i); poll ist ebenfalls Level-Triggered Vorteile gegenüber select pollkönnen beliebige Deskriptornummern übergeben werden 8. 8 Solange die entsprechenden Deskriptoren existieren, d.h. einen vorhanden I/O Kanal darstellen 8

9 KAPITEL 1. CLIENT/SERVER PROGRAMMIERMODELLE poll: Einschränkungen und Probleme Als Datenstruktur verwendet poll ein einziges Array für alle Deskriptoren. Falls man die Obergrenze der gleichzeitig offenen Verbindungen nicht kennt und dies ist der Normalfall muss das pollfds-array zur Laufzeit (re-)organisiert werden (z.b. mit realloc). Dies ist aber nur mit linearem Zeitaufwand möglich und daher bei größeren Deskriptorenmengen (> 1000) nicht akzeptabel. Falls es aus Designgründen nicht möglich ist, die Deskriptoren linear sortiert im Array zu halten (d.h.: pollfds[x].fd= X), muss sogar jeder einzelne Deskriptor linear gesucht werden! Ein weiterer Grund, der poll für große Sets disqualifiziert, ist der Kopieraufwand: Das pollfds- Array muss bei jedem Aufruf der poll-funktion vom User in den Kernelspace transferriert werden (und nach Aktualisierung aller reventsfelder wieder zurück). Da aber im Normallfall nur an einem geringen Anteil der Deskriptoren auch tatsächlich I/O durchgeführt wird, ist ein großteil dieses Aufwandes nutzlos. Das der Anwender wie beiselect selbst alle Deskriptoren verwalten muss, fällt dabei kaum noch ins Gewicht. 1.6 Das alternative poll-interface /dev/poll Sun versucht mit einer alternativen Schnittstelle die Nachteile von poll zu umgehen. /dev/poll löst die beiden größten Designschwächen: Kein Userspace-Array mehr notwendig Kopieraufwand Kernelspace Userspace entfällt Dabei wird die von poll bekannte pollfd-struktur weiter verwendet. Dazu werden anstatt ein Deskriptoren-Array zu verwenden jeweils ein (oder mehrere) pollfd-strukturen mittels der Gerätedatei /dev/poll an den Kernel übergeben. Dabei wird der Systemaufruf poll nicht mehr verwendet; an seine stelle treten die Systemaufrufe open, write und ioctl. Beispiel: int pollfd = open("/dev/poll", O_RDWR); struct pollfd p = {.events = POLLIN,.fd = 0 ; write(pollfd, &p, sizeof p); /* fd struktur dem kernel-set hinzufuegen */ struct pollfds p[100]; 9

10 KAPITEL 1. CLIENT/SERVER PROGRAMMIERMODELLE struct epoll_event { uint32_t events; /* Epoll events */ epoll_data_t data; /* User data variable */ Abbildung 1.2: pollfd - Strukur struct dvpoll dvp = {.dp_timeout = -1;.dp_nfds = 100;.dp_fds = p; ; ret = ioctl(io_masterfd, DP_POLL, &dvp); if (ret < 0) /* Fehlerbehandlung */ for (i=0; i < ret ; i++) { if (p[i].revents & POLLIN) lese_daten(i); if (pollfds[i].revents & POLLOUT) schreibe_daten(i); Der ioctl Aufruf wartet dann analog zu poll() auf Ereignisse und legt die Resultate in einen vom Programmierer angegebenen Speicherbereich. Da nur die Deskriptoren, die für die gewünschten I/O-Operationen zu verfügung stehen kopiert werden, entfällt sowohl die lineare Suche nach Ereignissen als auch der unnötige Kopieraufwand für das vollständige Set. Damit ist /dev/poll auch für die Verwendung bei einer hohen Anzahl an Verbindungen geeignet. Ein weiter Vorteil ist, das eine Portierung von poll auf /dev/poll schnell möglich ist. Gegen die Verwendung spricht, das dieses Interface derzeit nur unter SunOS (ab 5.8, Updates für 5.7 verfügbar) und aktuellem HP/UX zu verfügung steht. 1.7 Linux 2.6: epoll Das erstmals in Linux (2002) integrierte epoll ist /dev/poll ähnlich, verwendet allerdings ausschließlich neu Systemaufrufe (epoll_create, epoll_ctl, epoll_wait). Anstelle der pollfdstruktur tritt struct epoll_event ( 1.2. epoll_data_t ist ein union, in dem der Anwender eine beliebige Information mit dem Ereignis verbinden kann. Normalerweise ist dies der Dateideskriptor, es kann aber auch beispielsweise ein Zeiger auf eine Datenstruktur mit Zustandsinfomationen übergeben werden 9. epoll ist wahlweise Level oder Edge-Triggered. 9 Der Kernel verwendet diese Informationen nicht; sie dient ausschließlich dem Entwickler 10

11 KAPITEL 1. CLIENT/SERVER PROGRAMMIERMODELLE typedef union epoll_data { void *ptr; int fd; uint32_t u32; uint64_t u64; epoll_data_t; Abbildung 1.3: pollfd - Strukur Readiness Notification mit epoll Normalerweise verhält sich epolllevel-triggered und ist in der Anwendung mit /dev/poll vergleichbar. Beispiel: int epollfd = epoll_create(100); struct epoll_event ev = {.events = EPOLLIN ; ev.data.fd = 0; epoll_ctl(epollfd,epoll_ctl_add, fd, &ev); /* zum kernel set hinzufuegen */ struct epoll_event epoll_ev[100]; int ret = epoll_wait(epollfd, epoll_ev, 100, timeout); if (ret < 0) /* Fehlerbehandlung */ for (i=0; i < ret ; i++) { if (epoll_ev[i].events & (EPOLLIN EPOLLPRI)) lese_daten(i); if (epoll_ev[i].events & EPOLLOUT) schreibe_daten(i); Change Notification mit epoll Epoll unterstützt auch ein auf Change Notification -aufsetzendes Design. Dazu wird das EPOLLET-Flag im event-feld der epoll_event-struktur gesetzt. Bei Verwendung des Edge- Triggered-Mode muss vor dem nächsten epoll_wait-aufruf sicher gestellt sein, das der Deskriptor seinen Zustand geändert hat, z.b. in dem alle im Empfangspuffer befindliche Daten 11

12 KAPITEL 1. CLIENT/SERVER PROGRAMMIERMODELLE gelesen wurden. Bei mehreren tausend Deskriptoren ist dies aber nicht in einem akzeptablen Zeitfenster möglich, da andere Verbindungen nicht mehr bedient werden können. Daher muss stattdessen eine Datenstruktur mit aktiven Dateideskriptoren mitgeführt werden. Ein von epoll_wait geliefertes Ereignis wird dann in diese Datenstruktur eingefügt. Der Vorteil des Change-Notification Ansatzes ist, das die Applikation nicht mehr über gleichbleibende Ereignisse Informiert werden muss und somit bei vielen aktiven Deskriptoren weniger überflüssige Zustände zwischen Kernel- und Userspace ausgetauscht werden müssen. Der Nachteil besteht in der erhöhten Komplexität für den Anwendungsentwickler, da die Warteschlange bereiter Verbindungen nicht nur aktuell gehalten werden muss ein Deskriptor, der in der Datenstruktur nicht mehr verzeichnet ist, aber seinen Zustand nicht verändert hat, bleibt im Gegensatz zum Konzept der Readiness Notification hängen und wird nicht mehr bedient sondern sie muss auch sicherstellen, das alle Elemente der Struktur (d.h. alle Clients) in regelmässigen Abständen an die Reihe kommen und es zu keiner Benachteiligung kommt. 1.8 BSD: kqueue Das ursprünglich unter FreeBSD 10, inzwischen aber auch unter OpenBSD, NetBSD (und MacOS X) verfügbare Event-Interface stellt einen allumfassenden filterbasierten Ansatz dar. Im Gegensatz zu allen anderen gängigen Event-Handlern ermöglicht kqueue z.b. auch die Überwachung von Signalhandlern und Timern, bietet also eine einheitliche Schnittstelle für alle Arten von Ereignissen an. struct kevent { uintptr_t ident; /* identifier for this event */ short filter; /* filter for event */ u_short flags; /* action flags for kqueue */ u_int fflags; /* filter flag value */ intptr_t data; /* filter data value */ void *udata; /* opaque user data identifier */ ; int kfd = kqueue(); struct kevent kev; struct kevent res[100]; EV_SET(&kev, fd, EVFILT_READ,EV_ADD EV_ENABLE, 0, 0, 0); 10 Version 4.1 (2000) 12

13 KAPITEL 1. CLIENT/SERVER PROGRAMMIERMODELLE ret = kevent(kfd, &kev, 1, res, 100, NULL); if (ret < 0) /* Fehlerbehandlung */ for (i = 0; i < ret; i++) { switch (res[i].filter) { case EVFILT_READ: handle_read((int)res[i].ident); break; case EVFILT_WRITE: handle_read((int)res[i].ident); break; case EV_ERROR: /* Fehlerbehandlung */ 1.9 kevent Auch unter Linux gibt es inzwischen Bestrebungen, die verschiedenen Event-Handling Mechanismen zusammenzufassen. Evgeny Polyakov stellt diese neue Schnittstelle kevent als Patch für aktuelle 2.6-Kernel zur Verfügung. Sie kombiniert Ideen aus AIO und BSD kqueue und ersetzt die zahlreichen verschiedenen Ereignis-Subsysteme: Deskriptoren-Handling (select, poll,epoll): KEVENT_POLL Socket-Handling: KEVENT_SOCKET Ereignisse im DAteisystem: (inotify()): KEVENT_INODE Asynchrone I/O Ereignisse auf NEtzwerkebene: KEVENT_NAIO Timer: KEVENT_TIMER Polyakov gibt für aktive http-verbindungen folgende Daten an: kevent: req/s epoll: req/s Derzeit ist aber noch nicht abzusehen, ob und wann das kevent-system in den offiziellen Kernel einfliessen wird, obwohl der kevent-autor inzwischen die Integration empfiehlt ( consider for inclusion ) libevent Die Libevent-Bibliothek von Niels Provos ([Pro06]) stellt ein API bereit, welches den genauen Event-Mechanismus kapselt. Derzeit unterstützt libevent folgende Systemschnittstellen: 13

14 KAPITEL 1. CLIENT/SERVER PROGRAMMIERMODELLE select, poll /dev/poll epoll kqueue Zusätzlich bietet libevent seit Release 1.2 auch Funktionen für asynchrone DNS-Anfragen. Die von libevent bereitgestellte Abstraktionsschicht ist callback-basiert, d.h. libevent führt bei auftreten bestimmter Ereignisse wie z.b. Timeouts oder neue Daten in einem Socketpuffer zuvor durch den Nutzer der Bibliothek registrierte Funktionen aus. Diese haben den Prototyp void cbfunc(int fd, short eventmask, void *arg); eventmaskist ein Bitfeld, in dem Ereignisabhängige Flags gesetzt werden. Vorgehen: 1. Bibliothek initialisieren: +event_init()+ 2. struct event initialisieren (event_set) 3. Zu aktiven Events hinzufügen (event_add) 4. Event-Verarbeitung starten: +event_dispatch()+ event_init(); struct event ev; event_set(&ev, sock, EV_READ, cbfunc, &ev); event_add(&evfifo, NULL); event_dispatch(); void cbfunc(int fd, short mask, void *arg) { struct event *e = arg; ssize_t len; char buf[1024]; event_add(ev, NULL); 14

15 KAPITEL 1. CLIENT/SERVER PROGRAMMIERMODELLE len = read(fd, buf, sizeof buf); if (len < 0) perror("read"); else verarbeite(buf, len); Eine Besonderheit sollte nicht unerwähnt bleiben: Ein callback wird nicht erneut ausgeführt; falls dieselbe Funktion bei erneutem auftreten desselben Ereignisses wieder aufgerufen werden soll, muss der Callback-Handler die Eventstruktur erneut in das aktive Set übernehmen (event_add). 15

16 2 Effizientere TCP-Behandlung In den vorherigen Kapitel wurden Optimierungsmodelle vorgstellt um mehrerer Verbindungen effizient zu behandeln. Dieses Kapitel geht speziell darauf ein wie ein separierter TCP-Flow optimiert werden kann. Spezielle Socketoperationen via setsockopt() sollen an dieser Stelle nicht betrachtet werden es geht viel mehr um das Vermeiden von unnötigen Kopieroperationen. Dies wird in der Regel Zero-Copy betitelt. 2.1 Zero-Copy Die typische Lehrbuch herangehensweise eine Datei zu kopieren ist ungefähr die folgende: while((cnt = read(filefd, buf, buflen)) > 0) { char *bufptr = buf; do { ssize_t written = write(socket, bufptr, cnt); /* handle errors, if any... */ cnt -= written; bufptr += written; while (cnt > 0); Positiv daran anzumerken ist das es relativ einfach zu implementieren und auch für den unbegabten Programmierer einfach zu verstehen ist. Negativ ist das es für das Betriebssytem einige Hürden in den Weg stellt da es eine wichtige Optimierungsmethode nicht erkennen kann. Was in den Beispielcode passiert ist folgendes: Daten werden vom der Festplatte in den Kerneigenen Cache geschrieben. Dies ist in aller Regel als DMA 1 implementiert. Die CPU ist nur insoweit involviert das es Vor- und Nacharbeiten erledigt. Denn eigentlichen Kopierprozeß übernimmt dedizierte Hardware. 1 Direct Memory Access 16

17 KAPITEL 2. EFFIZIENTERE TCP-BEHANDLUNG Von diesem Kernelspeicher werden die Daten in den vorher allokieren Puffer (Variablenname: buf) kopiert. Dies wird dieses mal von der CPU direkt ausgeführt. Anschließend werden diese Daten mit dem write() Funktionsaufruf an den Socket kopiert. Der etwas flapsig verwendete Begriff Socket mein in diesem Fall einen Speicherbereich im Kern welche die Nutzdaten für das Paket enthält. Nachdem alle Vorbereitungsarbeiten abgeschloßen sind, dass sind zum großen Teil Protokoll spezifische Aufgaben 2, werden die Daten an die Netzwerkkarte übergeben. In der Regel auch eine DMA-Operation. Abbildung 2.1: Read - Write Kopiereschema Abbildung 2.1 visualisiert den Prozeß des Kopieres sofort wird die Redundanz deutlich. Die Erkentniss, welche aus dieser Kopierorgie gezogen werden kann ist das dass unnötige Kopieren in den Userspace Puffer vermieden werden sollte, sowie das ein nicht unbedeutende Anzahl an Syscalls involviert ist. Dies ist ein nicht zu unterschätzender Perfomanceverlusst! 2.2 Speicher Abbildungen - Die Funkion mmap Ein nicht primär für diesen Zweck, den Einsparen von Kopieraufrufen, entworfene Funktion kommt den Programmierer aber Zuhilfe. Die Funktion mmap() mapped eine Datei in den Speicherbereich. Der Speicherbereich ab wo auf die Datei zugegriffen werden kann wird von mmap() als Rückgabewert geliefert. Positiver Nebeneffekt ist das bei dieser Aufrufsemantik die Daten nicht in den Userspace- Adressraum kopiert werden muss. Auch wenn mehrer Prozeße auf diesem Bereich lesend verwenden muss dieser Bereich nur einmal in gesammten physikalischen Arbeitsspeicher vorgehalten werden. Abbildung 2.2 auf der nächsten Seite zeigt den eingesparten Kopieraufruf. Es sind aber troztalledem noch vier Kontext-Switche nötig. 2 Segmentierung auf MSS Größe sowie Prüfsummenberechnung, etc 17

18 KAPITEL 2. EFFIZIENTERE TCP-BEHANDLUNG Ein Problem ergibt sich aus der Tatsache falls ein anderer Prozeß die Datei kürzt! Dabei wird als Standardbehandlung das Signal SIGBUS geliefert worauf der Prozeß sich ohne besondere Vorkehrung beendet dies muss verhindert werden! Abbildung 2.2: Mmap - Speichermappings anlegen 2.3 Sendfile Speichermappings sind nur eine Karte um diesen entgegenzuwirken, ideal ist es nicht. Dieser Umstand war und ist bekannt und es wurden Gegenmaßnahmen getroffen um diesen entegenzuwirken. Die Funktion sendfile() welchen folgenden Prototypen unter Linux besitzt geht einen speziellen, aber wirkungsvollen Weg: ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count); Sendfile verlangt einen Ausgabedeskriptor, einen Socket. Als Eingabedeskriptor muss eine geöffnete Datei angegeben werden und als verbleibende Argumente die Stelle ab wo die Daten kopiert werden sollen, sowie die Länge. Drei entscheidende Vorteile ergeben sich aus der Verwendung von Sendfile: 1. Nur ein Systemaufruf für die gesammte Datei wird beötigt 2. Es muss kein Puffer im Userspace allokiert werden 3. Keine Daten müssern in den Userspace kopiert werden Trotz all den Vorteilen verbleibt ein CPU: vom Dateisystem-Cache in dem Socketpuffer. Abbildung 2.3 auf der nächsten Seite zeigt die Kopieraufrufe grafisch. Leider ist sendfile alles anderer portabel zwar ist es unter fast allen gängigen Unix- Deriaten vorhanden, doch der Funktionsprototyp ist nicht einheitlich eventuell liegt darin die mangelde Verwendung dieser netten Funktion begründet. So erwartet sendfileunter *BSD zusätzlich ein (optionales) iovec-array diese Daten werden vor der Datei an den Client geschickt. Dies ist nützlich, wenn wie z.b. bei http vor den eigentlichen Nutzdaten ein Header vorangestellt werden muss. 18

19 KAPITEL 2. EFFIZIENTERE TCP-BEHANDLUNG Abbildung 2.3: Filetransfer mit sendfile 2.4 TCP-Cork Unter Linux kann dieses Problem mit der Socket-Option TCP_CORK gelöst werden: int one = 1, zero = 0; socklen_t len = sizeof(one); setsockopt(socket,ipproto_tcp,tcp_cork, &one, &len); write(socket,...); write(socket,...); setsockopt(socket,ipproto_tcp,tcp_cork, &zero, &len); Falls diese Socket-Option gesetzt ist, werden alle Daten im Socket-Puffer akkumuliert und erst gesendet wenn Der Puffer voll ist Ein Timeout-Grenze überschritten ist Die Option wieder entfernt wird Unter *BSD existiert die Option TCP_NOPUSH, die verlgeichbar mit TCP_CORK ist. Für UDP- Verbindungen bietet Linux UDP_CORK. 2.5 writev Eine Portablere Lösung ist die Verwendung von gather write ([Ste04]): struct iovec { void *iov_base;size_t iov_len; ; ssize_t writev(int fd, const struct iovec *vector, int count); 19

20 KAPITEL 2. EFFIZIENTERE TCP-BEHANDLUNG Zwei Eigenschaften erschweren die Verwendung von writev(): Erstens ist die Anzahl der maximal Verwendbaren Vektoren ist auf IOV_MAX Vektoren beschränkt, es ist also notwendig vor einem writev-aufruf zu testen, ob mehr IOV_MAX Vektoren vorhanden sind wenn ja, müssen diese Vektoren auf mehrere writev-aufrufe verteilt werden. Zweitens muss falls der Rückgabewert positiv ist, aber kleiner als die Summe aller Puffergrößen des Vektors alle Elemente des Vektors durchgezählt werden, um zu ermitteln welche Vektoren nicht geschrieben wurden und ggf. die Pufferinhalte und Längen zu korrigieren. struct iovec iovecs[10]; int iov_total = sizeof iovecs / sizeof iovecs[0]; ssize_t bytes_total = 0; iovecs[0].iov_len = 23; iovecs[0].iov_base = buffer_1; iovecs[1].iov_len = 42; iovecs[1].iov_base = buffer_2; do { ssize_t ret; int iovlen = iov_total > IOV_MAX? IOV_MAX : iov_total; for (i=0; i < iovlen; i++) bytes_total += iovecs[i].iov_len; ret = writev(sock, iovecs, iovlen); if (ret < 0) { if (errno == EINTR errno == EAGAIN) continue; break; if (ret < bytes_total) { ssize_t written = 0; for (i=0; i < iovlen; i++) { ssize_t leftover; written += iovecs[i].iov_len; if (written < ret) continue; written -= iovecs[i].iov_len; leftover = ret - written; if (leftover) { char *buf = iovecs[i].iov_base + iovecs[i].iov_len; iovecs[i].iov_base = buf - leftover; iovecs[i].iov_len = leftover; 20

21 KAPITEL 2. EFFIZIENTERE TCP-BEHANDLUNG iovlen -= i; if (!leftover && iovlen < iov_total) iovlen++; break; iov_total -= iovlen; while (iov_total); 2.6 Splice und Tee Splice und Tee sind die Newcomer im Linux Betriebssytem, sie generalisieren das Konzept von einer Userspacefreien Kopierfunktion splice long splice(int, loff t, int, loff t, size t, unsigned int); ist der aktuelle Protoyp für splice(). Als Ein- und Ausgabedeskriptor kann jeder Deskriptor dienen welcher sys_splice Implenetiert. Aktuell ist dies jede Datei im Dateisystem sowie die Sockets, damit ist ein großes Anwendungsgebiet abgedeckt. Abstrakt kann man sich Splice als eine Funktion vorstellen welche Zugriff auf den Kernelspeicher liefert. Implementiert ist splice als eine In-Kernel-Pipe auf welcher zugegriffen werden kann. Eingeführt wurde splice ab Kernelversion in rc1. Anwendungen sind unter anderen folgende: Socket zu Socket (redirect) kopieren Datei nach Datei kopieren Messungen habe ergeben das eine Steigerung der Datentransferrate um bis 70% möglich ist. Dies bei einer Reduktion der CPU-Last um bis zu 50%! Eine einfache Implentierung welche vom Autor von splice() vorgeschlagen wurde könnte wie folgt implementiert sein: [...] in_fd = open(argv[index], O_RDONLY); if (in_fd < 0) return error("open input"); 21

22 KAPITEL 2. EFFIZIENTERE TCP-BEHANDLUNG if (fstat(in_fd, &sb) < 0) return error("stat input"); out_fd = open(argv[index + 1], O_WRONLY O_CREAT O_TRUNC, 0644); if (out_fd < 0) return error("open output"); if (pipe(pfds) < 0) return error("pipe"); do { int this_len = min((off_t) BS, sb.st_size); int ret = splice(in_fd, NULL, pfds[1], NULL, this_len, 0); if (ret <= 0) return error("splice-in"); sb.st_size -= ret; while (ret > 0) { int written = splice(pfds[0], NULL, out_fd, NULL, ret, splice_flags); if (written <= 0) return error("splice-out"); ret -= written; while (sb.st_size); close(in_fd); close(pfds[1]); close(out_fd); close(pfds[0]); [...] Tee Tee kann man sich als memcpy() von Kernelpuffer zu Kernelpuffer vorstellen. Es kopiert Daten im KS-Puffer. Eine Anwendung die Linus Torvalds vorgeschlagen hat war des Streamen von einen Hardware MPEG-Encoders zu einer Datei sowie an einen Socket. Wer das Userspace Programm tee kennt ist mit der Semantik schnell vertraut. 22

23 Literaturverzeichnis [Dre00] Ulrich Drepper. Asynchronous hostname lookup api a proposal [Dre06] [Mau03] Ulrich Drepper. The need for asynchronous, zero-copy network i/o problems and possible solutions Wolfgang Mauerer. Linux Kernelarchitektur Konzepte, Strukturen und Algorithmen von Kernel 2.6. Hanser, 1st edition, [MNN04] Marshall Kirk McKusick and George V. Neville-Neil. The Design and Implementation of the FreeBSD Operating System. Addison Wesley, 2nd edition, [Pro06] Niels Provos. libevent asynchronous event notification library. provos/libevent/, November [SR05] W. Richard Stevens and Stephan A. Rago. Advanced Programming in the Unix Environment. Addison Wesley, 2nd edition, [Ste04] W. Richard Stevens. UNIX Network Programming (The Sockets Networking). Prentice Hall, 2nd edition,