Outlook TCP-Connections

Damit Outlook mit Exchange kommunizieren kann, muss es natürlich eine Verbindung per TCP oder HTTP aufbauen. Dabei ist es aber nicht mit einer einzigen TCP-Connection getan. Je nach Anwendungsfall baut Outlook mehrere TCP-Connections auf. Diese Seite beschreibt die Aspekte im Hinblick auf Migration und Betrieb.

Siehe dazu auch TCP-Connection Report

Viele statt einer ?

Rein technisch betrachtet würde auch Outlook eine einzige TCP-Connection reichen, über die die komplette Kommunikation betrieben wird. Aber in Realität nutzt Outlook mehrere parallele Verbindungen und das hat gute Gründe

  • Latenz
    Eine TCP-Verbindung ist bezüglich des maximal möglichen Durchsatzes nicht nur von der Bandbreite sondern vor allem der Latenzzeit abhängig. Anders als bei ICMP oder UDP sendet Outlook per TCP Daten weg und wartet auf eine Quittung. Das ist zwar kein "Ping Pong" sondern arbeitet mit einem Buffer, aber wenn der Buffer z.B. 64kByte groß ist und die Pakete 10ms für Hin und zurück brauchen, dann können maximal 100 Pufferinhalte übertragen werden- Mehr als 6,4 Megabyte/Sek oder 64MBit sind über eine TCP-Connection nicht möglich. Der TCP-Stack passt natürlich die Puffergröße der Latenz und den Paketverlustraten an aber es ist endlich. Erst durch eine parallele Verbindung können Zugriffe "parallelisiert" werden.
  • Dienste auf dem gleichen Server
    Die Parallelisierung gilt umso mehr, wenn verschiedene Dienste angefragt werden. Wenn Outlook per MAPI/TCP das Postfach liest, nutzt es andere Ports als wenn es das Offline Adressbuch per HTTPS runterlädt oder Frei/Belegt-Zeiten per EWS anfragt oder eine Suche im Postfach über den Server macht. Auch hier ist klar, dass das eine weitere TCP-Verbindung ist, die zudem die Abhängigkeit reduziert.
  • Ziele
    Zudem kann Outlook ja nicht nur ein Postfach, sondern auch Stellvertreter und andere Postfächer in anderen Exchange Organisationen parallel öffnen. Bei Stellvertretern ist vielleicht eine andere Exchange Frontend besser geeignet. Wenn sie in Deutschland ihr Postfach öffnen aber einen Raum in Asien abfragen, dann ist der direkte Weg von ihrem Client nach Asien meist effektiver als den deutschen Server als Relay zu nutzen. Das gilt um so mehr, wenn Sie ein Postfach in der Cloud oder einer anderen Organisation mit öffnen. Da könnte ihnen ihr eigener Exchange Server gar nicht helfen. Das gilt auch z.B. für einen Zugriff auf ein "Online Archiv" in der Cloud oder weitere Postfächer, die per POP3/IMAP4 eingebunden sein könnten.

Damit dürfte gut erklärt sein, warum Outlook mit mehr als einer TCP-Connection arbeiten wird. In Office 365 gehen wir von ca. 10 gleichzeitigen Connections als Mittelwert aus. Das bedeutet nicht, dass Outlook diese Verbindungen alle auch dauerhaft am Leben erhält. Bestimmte Abfragen sind "kurzfristig", d.h. die Verbindung wird für die Abfrage aufgebaut aber nach einigen Minuten ist sie wieder weg. Übrigens arbeiten Webbrowser genauso. Wenn Sie eine Webseite betrachten, dann wird zuerst einmal die HTML-Seite geladen aber für die darin enthaltenen Bilder, Stylesheets, Skripte etc. öffnen die meisten Browser zusätzliche Verbindungen, damit die Seite schnell aufbereitet werden kann und nicht eine "dicke Datei" die Anzeige verzögert.

Wo ist das Problem?

Nun könnten Sie sich auf den Standpunkt stellen, dass das alles doch gar kein Problem ist. TCP-Connections sind ja nicht teuer und jeder Client hat 65535 mögliche Quell-Ports. Das bisschen Overhead für den Aufbau der Verbindung (SYN/ACK) und das Aufrechthalten (Keep Alive) machen andere Clients ja auch so. Bis zu einem gewissen Maße haben Sie hier auch recht aber Sie dürfen nicht vergessen, dass einige der Outlook-Verbindungen "dauerhaft" bestehen. Schließlich will der Server ihrem Outlook auch schnell mitteilen, wenn eine neue Mail angekommen ist oder in einer Shared-Mailbox sich etwas getan hat. Da Outlook Clients aber manchmal hinter Proxy Server und NAT-Routern versteckt sind, kann der Exchange Server die Verbindung nicht von seiner Seite her aufbauen. Also muss Outlook die Verbindung initiieren und am Leben halten. Das kann aber zu Problemen führen, z.B.

  • TCP-Sessions bei NAT-Routern
    Die meisten "SoHo"-Router haben nur beschränkte Kapazitäten bei Speicher und CPU und können daher nur eine gewisse Menge an NAT-Zuordnungen speichern. Oft ist hier schon bei wenigen hundert Einträgen Schluss. Das ist für eine Familie mit vielleicht 10 aktiven Geräten ausreichend. Für Firmen natürlich nicht. Sie glauben aber gar nicht, wie viele "Filialen" nach und nach wachsen, Office 365 nutzen und damit an diese Grenzen kommen. Die Effekte sind das übliche "geht mal, geht mal nicht, Mails sehe ich erst nach einem Neustart, ..."
  • HTTP-Proxy
    Die gleiche Thematik gilt für Anwender, die über einen HTTP-Proxy auf Exchange zugreifen. Diese "Long Running HTTP-Sessions" belegen auf dem Proxy Speicher, der endlich ist. Oft fällt hier dann erst nach langer Zeit auch auf, dass ein Proxy vielleicht ein Speicherloch hat und sich "vollfrisst", weil die Verbindung nicht "weggeräumt" wird.
  • TCP-Sessions beim Loadbalancer
    Wenn Sie selbst Exchange betreiben und mehrere Server als DAG zusammengeschaltet haben, dann betreiben Sie in der Regel auch einen Loadbalancer davor. Clients greifen über diese Instanz auf die Services zu. Klar, dass der Loadbalancer jede aktive Verbindung sich "merken" und entsprechend dimensioniert sein muss. Das gilt besonders bei "HA"-Konfigurationen, bei denen zwei Loadbalancer auch noch ihre Session-Table abgleichen, so dass ein Failover ohne neuen Verbindungsaufbau erfolgt. Auch das ist wichtig, da ansonsten bei einem HLB-Failover alle Clients in sehr kurzer Zeit neue Verbindungen zu den nachgeschalteten Services aufbauen. Das kann dort dann eine Überlastsituation bewirken.
  • Lizenzen pro Connection.
    Mittlerweile habe ich auch gelernt, dass verschiedene Komponenten im LAN und WAN ihre Lizenz an den Anzahl der Connections festmachen. Das gilt z.B. für Systeme von Riverbed Steelhead und auch die die ein oder andere Firewall oder Loadbalancer fallen darunter. Wenn Outlook durch geänderte Protokolle (MAPI/HTTP statt MAPI/TCP) oder geänderte Serverversionen (2016 statt 2010) oder andere Client Versionen sich anders verhält, kann dies weitere Probleme nach sich ziehen

Daher ist es wichtig zu wissen, wie viele Connections ein Client in ihrer individuellen Umgebung geöffnet hat und wie sich Updates und Veränderungen auswirken.

Outlook Verhalten

Also müssen wir Outlook mal etwas genauer auf die Finger schauen. In einem Test habe ich daher Outlook mit einem Exchange Server 2010 verbunden und dabei erst einmal nur mein eigenes Postfach geöffnet und danach noch ein paar Stellvertreter eingebunden. Die Ergebnisse waren speziell für Exchange 2010 und Exchange 2013/2016-Umgebungen interessant, da hier auch ein Protokollwechsel von MAPI/TCP auf RPC/HTTP bzw. MAPI/HTTP erfolgt ist. Ich habe mir daher ein Postfach auf Exchange 2010 mit einigen Stellvertretern angelegt und eine kleine Versuchsreihe mit folgendem Ergebnis gestartet:

Client Mailbox RPC/TCP RPC/http MAPI/HTTP

Outlook2010

Exchange 2010

Wenig Verbindungen

Wenig Verbindungen

Nicht möglich

Outlook2010

Exchange 2016

Nicht möglich

Mehr Verbindungen

Mehr  Verbindungen

Es hängt also nicht alleine am Protokoll sondern auch am dahinter liegenden Exchange Server. Ein Outlook 2010 gegen Exchange 2010 scheint sich mit wenigen Verbindungen zufrieden zu geben. Sobald aber ein Exchange 2016 Server als Backend angesprochen wird, kommen mehr Verbindungen zum Einsatz. Zumindest habe ich das schon beobachtet und die ein oder andere Schätzung bezüglich der verfügbaren Proxy-Sessions und Source-Ports (NAT) mussten angepasst werden. Das ist natürlich ein Problem, wenn Drittprodukte dann nicht pro Bandbreite sondern pro Connection lizenziert werden, z.B. WAN-Optimierer (Riverbed), Proxy-Systeme oder Loadbalancer.

Quellenstudium

Mir war dieses geänderten Verhalten so auch nicht bewusst, zumal ich seit Office 365 als Faustregel immer die 10 Connections/Outlook predige. Aber dass Outlook mit MAPI/TCP so sparsam ist, ist mir erst aufgefallen, als Outlook/HTTP viel mehr Connections benötigt und damit an anderer Stelle ein Engpass aufgetreten ist. Dennoch habe ich mich auf die Suche nach Quellen zu dem Thema gemacht. Die meisten Artikel beschreiben aber sehr schön, dass MAPI/HTTP in vielen Fällen effektiver ist, also bisherige Protokolle und nur in manchen Fällen etwas mehr Bandbreite braucht. Hier ein paar Quellen:

MAPI/HTTP moves connectivity to a true HTTP request/response pattern and no longer requires two long-lived TCP connections to be open for each session between Outlook and Exchange…
…The change in communication between Exchange and Outlook has a small impact on the bytes sent over the wire. The header content in MAPI/HTTP is responsible for an increase in bytes transferred. In a typical message communications we have observed an average packet size increase of 1.2% versus Outlook Anywhere for a 50 KB average packet. In scenarios of data transfers over 10 MB the increase in bytes over the wire is 5-10%. These increases assumes an ideal network where connections are not dropped or resumed. If you consider real world conditions you may actually find MAPI/HTTP data on the wire may be lower than Outlook Anywhere. Outlook Anywhere lacks the ability to resume connections and the cost of re-syncing items can quickly outweigh the increase from the MAPI/HTTP header information.
Quelle: Link: https://blogs.technet.microsoft.com/exchange/2014/05/09/outlook-connectivity-with-mapi-over-http/

Ich würde das so interpretieren, dass MAPI/HTTP auf "guten Verbindungen" etwas mehr Bandbreite braucht aber auf schlechteren Leitungen gewinnt, da nicht immer eine Neuanmeldung erforderlich ist.

.. For each RPC connection, Outlook initiates two HTTP sessions: one session for outgoing data and one session for incoming data. If Outlook shows five connections to the Exchange server for the Exchange mailbox, public folders, and the directory service, there are actually ten HTTP sessions. It is possible to fill the queue of concurrent kernel requests in the Internet Information Services (IIS) application pool. If the queue of concurrent kernel requests is filled, performance on Outlook clients may be negatively affected…
Quelle: HTTP Sessions Established by Outlook by Using RPC over HTTP https://technet.microsoft.com/en-us/library/bb124771(v=exchg.65).aspx

Hier ist gut zu sehen, warum Outlook mehrere "RPC-Verbindungen" aufmacht, für jede er dann zwei HTTP-Connections benötigt. Komisch nur, dass ich das so nicht mit NETSTAT verifizieren konnte.

Aber auch die KB-Artikel von Riverbed sind aufschlußreich, vor allem weil dort ein sehr gutes Verständnis der Protokolle vorhanden sein sollte.

.. Remember that one of the improvements made by Microsoft with MAPI over HTTP is that it uses fewer TCP connections compared to previous Outlook-to-Exchange dialects. Therefore, when you use down negotiation, you increase the connection count compared to MAPI over HTTP…
Quelle: Riverbed Microsoft Exchange Email Optimization https://support.riverbed.com/bin/support/static/lrj6rq1evg0fnm7pekuq3j2md1/html/vte4p5uj2dkg9k1ukjv82835ci/sh_9.2_dg_protocols_html/index.html#page/sh_9.2_dg_protocols%2Fmapi.html%23ww309102

Riverbed bietet einen "Steelhead Cloud Accelerator (SC A)" an, mit dem Sie den Verkehr zwischen einem lokalen Client und Exchange Online optimieren können. Auch hier ist die Preisgestaltung und Staffelung interessant. Riverbed rechnet mit 10 Connections und 80kbps pro User


Quelle: Riverbed Licensing Frequently Asked Questions https://supportkb. riverbed.com/support/index?page=content&id=S16282

Eine Sache ist mir aber aufgefallen, wenn ich in einem MAPI-Profil zweimal den "Exchange Provider" addiert habe. Das können Sie zwar auch machen, um z.B. zwei Postfächer in der gleichen Organisation zu öffnen, aber es ist nicht supported.

„Outlook 2010, Outlook 2013, and Outlook 2016 let you add your delegate’s account to your own profile and lets your delegate add your account to their profile. However, although there is no warning message or error, this profile configuration is not supported.“ ;

“In Exchange Server 2010 Service Pack 1 (SP1), the new Auto Mapping feature automatically adds mailb oxes to the Outlook Navigation Pane if you have Full Access permission to the mailboxes. Outlook manages these additional mailboxes by using a specific permissions set. If you previously configure d these same mailboxes as multiple Exchange accounts in Das neue Outlook profile, you may experience unexpected behavior when you send mail by using those other mailboxes. This is because mailboxes that are accessed by using the Outlook multiple Exchange accounts functionality use a different permissions set from those mailboxes that a re added by Exchange Auto Mapping. Outlook tries to use both permission sets at the same time. This profile configuration is not supported.“
Quelle: Issues that can occur when you add multiple Exchange accounts in the same Outlook profile https://support.microsoft.com/en-us/help/981245/issu es-that-can-occur-when-you-add-multiple-exchange-accounts-in-the-same-outlo ok-profile

Nur weil etwas von der Software nicht verhindert wird, sollten Sie nicht drauf vertrauen, dass es auch erlaubt ist.

Outlook <> NetStat

Es gibt zudem eine kleine Diskrepanz zwischen den in Outlook angezeigten "Verbindungen" und den per NETSTAT sichtbaren Verbindungen. Oft gibt es ein paar NETSTAT-Verbindungen mehr. Das erkläre ich mit aber so, dass Outlook auch noch HTTPS-Verbindungen zu EWS, OAB und AUTODISCOVER auf macht, die im Outlook Fenster selbst aber nicht zu sehen sind.

Hier sehen Sie ein Outlook, welches zwei Exchange Postfächer in zwei Organisationen geöffnet hat. zudem hat ein Postfach ein paar zusätzliche Postfächer eingebunden. Nicht zu vergessen die POP/IMAP-Konten verschiedener Testpostfächer. Ich komme auf 12 "MAPI"-Verbindungen und 7 weitere IMAP-Verbindungen.

Beim Blick auf die aktiven TCP-Verbindungen erscheinen aber nur 7 "aktive" und 4 weitere inaktive (graue) Verbindungen. Interessanteweise kann man am Port gut sehen, dass keine einzige IMAP-Verbindung "besteht":

Verbindungen zum IMAP-Server werden aufgebaut, wenn ich in Outlook einen Ordner dieses Postfachs anwähle oder Outlook mal wieder im Hintergrund nachschaut. Anscheinend nutzt Outlook kein IMAP4-Push mit einer bestehenden Verbindung.

Weitere Links