TCP/IP-prestandajustering för virtuella Azure-datorer
I den här artikeln beskrivs vanliga tekniker för TCP/IP-prestandajustering och några saker att tänka på när du använder dem för virtuella datorer som körs i Azure. Den ger en grundläggande översikt över teknikerna och utforskar hur de kan finjusteras.
Vanliga TCP/IP-justeringstekniker
MTU, fragmentering och stor avlastning
MTU
Den maximala överföringsenheten (MTU) är den största storleksramen (paketet), som anges i byte, som kan skickas via ett nätverksgränssnitt. MTU är en konfigurerbar inställning. Standard-MTU:n som används på virtuella Azure-datorer och standardinställningen på de flesta nätverksenheter globalt är 1 500 byte.
Fragmentering
Fragmentering uppstår när ett paket skickas som överskrider MTU för ett nätverksgränssnitt. TCP/IP-stacken delar upp paketet i mindre delar (fragment) som överensstämmer med gränssnittets MTU. Fragmentering sker på IP-lagret och är oberoende av det underliggande protokollet (till exempel TCP). När ett paket på 2 000 byte skickas via ett nätverksgränssnitt med en MTU på 1 500, delas paketet upp i ett paket på 1 500 byte och ett paket med 500 byte.
Nätverksenheter i sökvägen mellan en källa och ett mål kan antingen släppa paket som överskrider MTU:n eller fragmentera paketet i mindre delar.
Biten Fragmenta inte i ett IP-paket
Df-biten (Don't Fragment) är en flagga i IP-protokollhuvudet. DF-biten anger att nätverksenheter på sökvägen mellan avsändaren och mottagaren inte får fragmenta paketet. Den här biten kan ställas in av många orsaker. (Se avsnittet "Path MTU Discovery" i den här artikeln för ett exempel.) När en nätverksenhet tar emot ett paket med bituppsättningen Don't Fragment och paketet överskrider enhetens MTU-gränssnitt är standardbeteendet att enheten släpper paketet. Enheten skickar tillbaka ett ICMP Fragmentation Needed-meddelande till den ursprungliga källan till paketet.
Prestandakonsekvenser av fragmentering
Fragmentering kan ha negativa prestandakonsekvenser. En av de främsta orsakerna till prestandaeffekten är processor-/minnespåverkan av fragmenteringen och återmonteringen av paket. När en nätverksenhet behöver fragmentera ett paket måste den allokera PROCESSOR-/minnesresurser för att utföra fragmentering.
Samma sak händer när paketet monteras ihop igen. Nätverksenheterna måste lagra alla fragment tills de tas emot så att de kan monteras på nytt i det ursprungliga paketet.
Azure och fragmentering
Fragmenterade paket i Azure bearbetas inte av accelererat nätverk. När en virtuell dator tar emot ett fragmenterat paket bearbetas det via den icke-accelererade sökvägen. Det innebär att fragmenterade paket inte får fördelarna med accelererat nätverk (lägre svarstid, minskad jitter och högre paket per sekund). Därför rekommenderar vi att du undviker fragmentering om möjligt.
Som standard hoppar Azure ur ordningsfragment, dvs fragmenterade paket som inte kommer till den virtuella datorn i den ordning som de skickades från källslutpunkten. Detta kan inträffa när paket överförs via Internet eller andra stora WAN-nätverk. Omordning av fragment i fel ordning kan aktiveras i vissa fall. Om ett program kräver detta öppnar du ett supportärende.
Justera MTU
Vi rekommenderar inte att kunderna ökar MTU på virtuella datorkort. Om den virtuella datorn behöver kommunicera med mål som inte finns i det virtuella nätverket som har en liknande MTU-uppsättning uppstår sannolikt fragmentering som minskar prestandan.
Stor sändningslast
Stor avlastning (LSO) kan förbättra nätverksprestanda genom att avlasta segmenteringen av paket till Ethernet-adaptern. När LSO är aktiverat skapar TCP/IP-stacken ett stort TCP-paket och skickar det till Ethernet-adaptern för segmentering innan det vidarebefordras. Fördelen med LSO är att den kan frigöra processorn från att segmentera paket i storlekar som överensstämmer med MTU och avlasta bearbetningen till Ethernet-gränssnittet där det utförs i maskinvara. Mer information om fördelarna med LSO finns i Stöd för stor sändningslast.
När LSO är aktiverat kan Azure-kunder se stora ramstorlekar när de utför paketinsamlingar. Dessa stora ramstorlekar kan leda till att vissa kunder tror att fragmentering sker eller att en stor MTU används när den inte är det. Med LSO kan Ethernet-adaptern annonsera en större maximal segmentstorlek (MSS) till TCP/IP-stacken för att skapa ett större TCP-paket. Hela den här icke-segmenterade ramen vidarebefordras sedan till Ethernet-adaptern och visas i en paketinsamling som utförs på den virtuella datorn. Men paketet kommer att delas upp i många mindre ramar av Ethernet-adaptern, enligt Ethernet-adapterns MTU.
TCP MSS-fönsterskalning och PMTUD
Maximal segmentstorlek för TCP
TCP maximum segment size (MSS) är en inställning som begränsar storleken på TCP-segment, vilket undviker fragmentering av TCP-paket. Operativsystem använder vanligtvis den här formeln för att ange MSS:
MSS = MTU - (IP header size + TCP header size)
IP-huvudet och TCP-huvudet är 20 byte vardera, eller totalt 40 byte. Ett gränssnitt med en MTU på 1 500 har därför en MSS på 1 460. Men MSS kan konfigureras.
Den här inställningen godkänns i TCP-trevägshandskakningen när en TCP-session har konfigurerats mellan en källa och ett mål. Båda sidor skickar ett MSS-värde och det nedre av de två används för TCP-anslutningen.
Tänk på att MTU:er för källan och målet inte är de enda faktorerna som avgör MSS-värdet. Mellanliggande nätverksenheter, till exempel VPN-gatewayer, inklusive Azure VPN Gateway, kan justera MTU oberoende av källa och mål för att säkerställa optimala nätverksprestanda.
Sökväg till MTU-identifiering
MSS förhandlas, men det kanske inte anger den faktiska MSS som kan användas. Det beror på att andra nätverksenheter i sökvägen mellan källan och målet kan ha ett lägre MTU-värde än källan och målet. I det här fallet släpper den enhet vars MTU är mindre än paketet paketet. Enheten skickar tillbaka ett ICMP-fragmenteringsmeddelande (typ 3, kod 4) som innehåller dess MTU. Med det här ICMP-meddelandet kan källvärden minska sin Path MTU på rätt sätt. Processen kallas Path MTU Discovery (PMTUD).
PMTUD-processen är ineffektiv och påverkar nätverksprestanda. När paket skickas som överskrider en nätverkssökvägs MTU måste paketen överföras igen med en lägre MSS. Om avsändaren inte tar emot meddelandet ICMP Fragmentation Needed, kanske på grund av en nätverksbrandvägg i sökvägen (kallas ofta för ett PMTUD-svarthål), vet avsändaren inte att den behöver sänka MSS och kommer kontinuerligt att överföra paketet igen. Därför rekommenderar vi inte att du ökar MTU:n för den virtuella Azure-datorn.
VPN och MTU
Om du använder virtuella datorer som utför inkapsling (till exempel virtuella IPsec-VPN:er) finns det några ytterligare överväganden när det gäller paketstorlek och MTU. VPN lägger till fler huvuden i paket, vilket ökar paketstorleken och kräver en mindre MSS.
För Azure rekommenderar vi att du anger TCP MSS-klämning till 1 350 byte och tunnelgränssnittet MTU till 1 400. Mer information finns på sidan VPN-enheter och IPSec/IKE-parametrar.
Skalning av svarstider, tur och retur-tid och TCP-fönster
Svarstid och tur och retur-tid
Nätverksfördröjning styrs av ljusets hastighet över ett fiberoptiskt nätverk. Nätverkets dataflöde för TCP styrs också effektivt av tidsåtgången (RTT) mellan två nätverksenheter.
| Flöde | Avstånd | Enkelriktad tid | RTT |
|---|---|---|---|
| New York till San Francisco | 4 148 km | 21 ms | 42 ms |
| New York till London | 5 585 km | 28 ms | 56 ms |
| New York till Sydney | 15 993 km | 80 ms | 160 ms |
Den här tabellen visar det räta avståndet mellan två platser. I nätverk är avståndet vanligtvis längre än det räta avståndet. Här är en enkel formel för att beräkna minsta RTT som styrs av ljusets hastighet:
minimum RTT = 2 * (Distance in kilometers / Speed of propagation)
Du kan använda 200 för spridningshastigheten. Detta är avståndet, i kilometer, som ljuset färdas i 1 millisekunder.
Vi tar New York till San Francisco som exempel. Det räta avståndet är 4 148 km. När vi ansluter det värdet till ekvationen får vi följande:
Minimum RTT = 2 * (4,148 / 200)
Ekvationens utdata är i millisekunder.
Om du vill få bästa nätverksprestanda är det logiska alternativet att välja mål med det kortaste avståndet mellan dem. Du bör också utforma ditt virtuella nätverk för att optimera trafiksökvägen och minska svarstiden. Mer information finns i avsnittet "Överväganden vid nätverksdesign" i den här artikeln.
Svarstid och tidseffekter för tur och retur på TCP
Tur- och returtid har en direkt effekt på maximalt TCP-dataflöde. I TCP-protokollet är fönsterstorleken den maximala mängden trafik som kan skickas via en TCP-anslutning innan avsändaren behöver ta emot bekräftelse från mottagaren. Om TCP MSS är inställt på 1 460 och TCP-fönsterstorleken är inställd på 65 535, kan avsändaren skicka 45 paket innan den måste ta emot bekräftelse från mottagaren. Om avsändaren inte får bekräftelse kommer den att överföra data igen. Här är formeln:
TCP window size / TCP MSS = packets sent
I det här exemplet avrundas 65 535 /1 460 upp till 45.
Det här tillståndet "väntar på bekräftelse", en mekanism för att säkerställa tillförlitlig dataleverans, är det som gör att RTT påverkar TCP-dataflödet. Ju längre avsändaren väntar på bekräftelse, desto längre tid behöver den vänta innan mer data skickas.
Här är formeln för att beräkna det maximala dataflödet för en enda TCP-anslutning:
Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second
Den här tabellen visar det maximala dataflödet i megabyte/per sekund för en enda TCP-anslutning. (För läsbarhet används megabyte för måttenheten.)
| TCP-fönsterstorlek (byte) | RTT-svarstid (ms) | Maximalt megabyte/sekund-dataflöde | Maximalt megabit/sekund-dataflöde |
|---|---|---|---|
| 65,535 | 1 | 65.54 | 524.29 |
| 65,535 | 30 | 2.18 | 17.48 |
| 65,535 | 60 | 1.09 | 8.74 |
| 65,535 | 90 | .73 | 5,83 |
| 65,535 | 120 | 55. | 4.37 |
Om paket går förlorade minskas det maximala dataflödet för en TCP-anslutning medan avsändaren överför data som den redan har skickat.
Skalning av TCP-fönster
TCP-fönsterskalning är en teknik som dynamiskt ökar TCP-fönsterstorleken så att mer data kan skickas innan en bekräftelse krävs. I föregående exempel skulle 45 paket skickas innan en bekräftelse krävdes. Om du ökar antalet paket som kan skickas innan en bekräftelse behövs minskar du antalet gånger som en avsändare väntar på bekräftelse, vilket ökar TCP:s maximala dataflöde.
Den här tabellen illustrerar dessa relationer:
| TCP-fönsterstorlek (byte) | RTT-svarstid (ms) | Maximalt megabyte/sekund-dataflöde | Maximalt megabit/sekund-dataflöde |
|---|---|---|---|
| 65,535 | 30 | 2.18 | 17.48 |
| 131,070 | 30 | 4.37 | 34.95 |
| 262,140 | 30 | 8.74 | 69.91 |
| 524,280 | 30 | 17.48 | 139.81 |
Men TCP-huvudvärdet för TCP-fönsterstorleken är bara 2 byte långt, vilket innebär att det maximala värdet för ett mottagningsfönster är 65 535. För att öka den maximala fönsterstorleken introducerades en TCP-fönsterskalningsfaktor.
Skalningsfaktorn är också en inställning som du kan konfigurera i ett operativsystem. Här är formeln för att beräkna TCP-fönsterstorleken med hjälp av skalningsfaktorer:
TCP window size = TCP window size in bytes * (2^scale factor)
Här är beräkningen för en skalningsfaktor för fönster på 3 och en fönsterstorlek på 65 535:
65,535 * (2^3) = 524,280 bytes
En skalningsfaktor på 14 resulterar i en TCP-fönsterstorlek på 14 (den maximala förskjutningen tillåts). TCP-fönsterstorleken blir 1 073 725 440 byte (8,5 gigabit).
Stöd för TCP-fönsterskalning
Windows kan ange olika skalningsfaktorer för olika anslutningstyper. (Klasser av anslutningar inkluderar datacenter, Internet och så vidare.) Du använder Get-NetTCPConnection PowerShell-kommandot för att visa anslutningstypen för fönsterskalning:
Get-NetTCPConnection
Du kan använda Get-NetTCPSetting PowerShell-kommandot för att visa värdena för varje klass:
Get-NetTCPSetting
Du kan ange den inledande TCP-fönsterstorleken och TCP-skalningsfaktorn i Windows med hjälp Set-NetTCPSetting av PowerShell-kommandot. Mer information finns i Set-NetTCPSetting.
Set-NetTCPSetting
Det här är de effektiva TCP-inställningarna för AutoTuningLevel:
| Autotuninglevel | Skalningsfaktor | Skalningsmultiplikator | Formel till beräkna maximal fönsterstorlek |
|---|---|---|---|
| Inaktiverat | Inga | Inga | Fönsterstorlek |
| Begränsad | 4 | 2^4 | Fönsterstorlek * (2^4) |
| Mycket begränsad | 2 | 2^2 | Fönsterstorlek * (2^2) |
| Normal | 8 | 2^8 | Fönsterstorlek * (2^8) |
| Experimentell | 14 | 2^14 | Fönsterstorlek * (2^14) |
De här inställningarna är mest sannolika att påverka TCP-prestanda, men tänk på att många andra faktorer på Internet, utanför Azures kontroll, också kan påverka TCP-prestanda.
Accelererad nätverks- och mottagarskalning
Accelererat nätverk
Nätverksfunktioner för virtuella datorer har tidigare varit processorintensiva på både den virtuella gästdatorn och hypervisor-värden. Varje paket som överförs via värden bearbetas i programvara av värdprocessorn, inklusive all inkapsling och inkapsling av virtuella nätverk. Ju mer trafik som går genom värden, desto högre cpu-belastning. Och om värdprocessorn är upptagen med andra åtgärder påverkar det även nätverkets dataflöde och svarstid. Azure löser det här problemet med accelererat nätverk.
Accelererat nätverk ger konsekvent ultralow nätverksfördröjning via den interna programmerbara maskinvaran i Azure och tekniker som SR-IOV. Accelererat nätverk flyttar mycket av den programvarudefinierade Nätverksstacken i Azure från processorerna och till FPGA-baserade SmartNICs. Den här ändringen gör det möjligt för slutanvändarprogram att återta beräkningscykler, vilket ger mindre belastning på den virtuella datorn, vilket minskar jitter och inkonsekvens i svarstiden. Prestanda kan med andra ord vara mer deterministiska.
Accelererat nätverk förbättrar prestandan genom att tillåta den virtuella gästdatorn att kringgå värden och upprätta en datasökväg direkt med en värds SmartNIC. Här följer några fördelar med accelererat nätverk:
Lägre svarstid/högre paket per sekund (pps): Om du tar bort den virtuella växeln från datasökvägen eliminerar du den tid som paketen spenderar på värden för principbearbetning och ökar antalet paket som kan bearbetas på den virtuella datorn.
Minskad jitter: Bearbetning av virtuella växlar beror på hur mycket princip som måste tillämpas och arbetsbelastningen för processorn som utför bearbetningen. Om du avlastar principtillämpningen till maskinvaran tar du bort variabiliteten genom att leverera paket direkt till den virtuella datorn, vilket eliminerar kommunikationen mellan värdar och virtuella datorer och alla programavbrott och kontextväxlar.
Minskad CPU-användning: Om du kringgår den virtuella växeln i värden leder det till mindre processoranvändning för bearbetning av nätverkstrafik.
Om du vill använda accelererat nätverk måste du uttryckligen aktivera det på varje tillämplig virtuell dator. Anvisningar finns i Skapa en virtuell Linux-dator med accelererat nätverk .
Ta emot sidoskalning
RSS (Receive Side Scaling) är en teknik för nätverksdrivrutiner som distribuerar mottagningen av nätverkstrafik effektivare genom att distribuera bearbetning av mottagna över flera processorer i ett system med flera processorer. Enkelt uttryckt tillåter RSS ett system att bearbeta mer mottagen trafik eftersom det använder alla tillgängliga processorer i stället för bara en. En mer teknisk diskussion om RSS finns i Introduktion för att ta emot sidoskalning.
För att få bästa prestanda när accelererat nätverk är aktiverat på en virtuell dator måste du aktivera RSS. RSS kan också ge fördelar på virtuella datorer som inte använder accelererat nätverk. En översikt över hur du avgör om RSS är aktiverat och hur du aktiverar det finns i Optimera nätverksdataflöde för virtuella Azure-datorer.
TCP TIME_WAIT och TIME_WAIT lönnmord
TCP-TIME_WAIT är en annan vanlig inställning som påverkar nätverks- och programprestanda. På upptagna virtuella datorer som öppnar och stänger många sockets, antingen som klienter eller som servrar (Käll-IP:Källport + Mål-IP:Målport), kan en viss socket under den normala driften av TCP hamna i ett TIME_WAIT tillstånd under en längre tid. Det TIME_WAIT tillståndet är avsett att tillåta att ytterligare data levereras på en socket innan du stänger den. TCP/IP-staplar förhindrar vanligtvis återanvändning av en socket genom att tyst släppa klientens TCP SYN-paket.
Hur lång tid en socket är i TIME_WAIT kan konfigureras. Det kan variera från 30 sekunder till 240 sekunder. Sockets är en begränsad resurs och antalet socketar som kan användas vid en viss tidpunkt kan konfigureras. (Antalet tillgängliga socketar är vanligtvis cirka 30 000.) Om de tillgängliga socketarna används, eller om klienter och servrar har felmatchade TIME_WAIT inställningar, och en virtuell dator försöker återanvända en socket i ett TIME_WAIT tillstånd, misslyckas nya anslutningar eftersom TCP SYN-paket tyst tas bort.
Värdet för portintervallet för utgående socketar kan vanligtvis konfigureras i TCP/IP-stacken för ett operativsystem. Samma sak gäller för TCP-TIME_WAIT inställningar och återanvändning av socketar. Om du ändrar dessa tal kan skalbarheten förbättras. Men beroende på situationen kan dessa ändringar orsaka samverkansproblem. Du bör vara försiktig om du ändrar dessa värden.
Du kan använda TIME_WAIT lönnmord för att åtgärda den här skalningsbegränsningen. TIME_WAIT lönnmord tillåter att en socket återanvänds i vissa situationer, till exempel när sekvensnumret i IP-paketet för den nya anslutningen överskrider sekvensnumret för det sista paketet från föregående anslutning. I det här fallet tillåter operativsystemet att den nya anslutningen upprättas (den accepterar den nya SYN/ACK) och tvingar den tidigare anslutningen som var i ett TIME_WAIT tillstånd att stängas. Den här funktionen stöds på virtuella Windows-datorer i Azure. Om du vill veta mer om support på andra virtuella datorer kan du kontakta OS-leverantören.
Mer information om hur du konfigurerar TCP-TIME_WAIT inställningar och källportintervall finns i Inställningar som kan ändras för att förbättra nätverksprestanda.
Virtuella nätverksfaktorer som kan påverka prestanda
Maximalt utgående dataflöde för virtuell dator
Azure har en mängd olika storlekar och typer av virtuella datorer, var och en med olika kombinationer av prestandafunktioner. En av dessa funktioner är nätverksdataflöde (eller bandbredd), som mäts i megabitar per sekund (Mbit/s). Eftersom virtuella datorer finns på delad maskinvara måste nätverkskapaciteten delas rättvist mellan de virtuella datorerna med samma maskinvara. Större virtuella datorer tilldelas mer bandbredd än mindre virtuella datorer.
Nätverksbandbredden som allokeras till varje virtuell dator mäts på utgående trafik (utgående) från den virtuella datorn. All nätverkstrafik som lämnar den virtuella datorn räknas mot den allokerade gränsen, oavsett mål. Om en virtuell dator till exempel har en gräns på 1 000 Mbit/s gäller den gränsen om den utgående trafiken är avsedd för en annan virtuell dator i samma virtuella nätverk eller utanför Azure.
Inkommande mäts inte eller begränsas direkt. Men det finns andra faktorer, till exempel cpu- och lagringsgränser, som kan påverka en virtuell dators möjlighet att bearbeta inkommande data.
Accelererat nätverk är utformat för att förbättra nätverksprestanda, inklusive svarstid, dataflöde och CPU-användning. Accelererat nätverk kan förbättra en virtuell dators dataflöde, men det kan bara göra det upp till den virtuella datorns allokerade bandbredd.
Virtuella Azure-datorer har minst ett nätverksgränssnitt kopplat till sig. De kan ha flera. Bandbredden som allokeras till en virtuell dator är summan av all utgående trafik över alla nätverksgränssnitt som är anslutna till datorn. Med andra ord allokeras bandbredden per virtuell dator, oavsett hur många nätverksgränssnitt som är anslutna till datorn.
Förväntat utgående dataflöde och antalet nätverksgränssnitt som stöds av varje VM-storlek beskrivs i Storlekar för virtuella Windows-datorer i Azure. Om du vill se maximalt dataflöde väljer du en typ, till exempel Generell användning, och hittar sedan avsnittet om storleksserien på den resulterande sidan (till exempel "Dv2-serien"). För varje serie finns det en tabell som innehåller nätverksspecifikationer i den sista kolumnen, som heter "Max NÄTVERKSKORT/Förväntad nätverksbandbredd (Mbit/s)."
Dataflödesgränsen gäller för den virtuella datorn. Dataflödet påverkas inte av följande faktorer:
Antal nätverksgränssnitt: Bandbreddsgränsen gäller för summan av all utgående trafik från den virtuella datorn.
Accelererat nätverk: Även om den här funktionen kan vara till hjälp för att uppnå den publicerade gränsen ändrar den inte gränsen.
Trafikmål: Alla mål räknas mot gränsen för utgående trafik.
Protokoll: All utgående trafik över alla protokoll räknas mot gränsen.
Mer information finns i Nätverksbandbredd för virtuella datorer.
Prestandaöverväganden för Internet
Som beskrivs i den här artikeln kan faktorer på Internet och utanför kontrollen av Azure påverka nätverksprestanda. Här är några av dessa faktorer:
Svarstid: Tur och retur-tiden mellan två mål kan påverkas av problem i mellanliggande nätverk, av trafik som inte tar den "kortaste" avståndsvägen och av suboptimala peering-sökvägar.
Paketförlust: Paketförlust kan orsakas av överbelastning i nätverket, problem med fysiska sökvägar och underpresterande nätverksenheter.
MTU-storlek/fragmentering: Fragmentering längs sökvägen kan leda till fördröjningar i data ankomst eller i paket som anländer i fel ordning, vilket kan påverka leveransen av paket.
Traceroute är ett bra verktyg för att mäta nätverksprestandaegenskaper (t.ex. paketförlust och svarstid) längs varje nätverkssökväg mellan en källenhet och en målenhet.
Överväganden för nätverksdesign
Tillsammans med de överväganden som beskrivs tidigare i den här artikeln kan topologin för ett virtuellt nätverk påverka nätverkets prestanda. En hub-and-spoke-design som backhauls trafik globalt till ett virtuellt nätverk med en enda hubb introducerar nätverksfördröjning, vilket påverkar övergripande nätverksprestanda.
Antalet nätverksenheter som nätverkstrafiken passerar genom kan också påverka den övergripande svarstiden. Om trafiken till exempel passerar via en virtuell ekernätverksinstallation och en virtuell hubbinstallation innan den överförs till Internet, kan de virtuella nätverksinstallationerna ge svarstid.
Azure-regioner, virtuella nätverk och svarstider
Azure-regioner består av flera datacenter som finns inom ett allmänt geografiskt område. Dessa datacenter kanske inte är fysiskt bredvid varandra. I vissa fall avgränsas de med så mycket som 10 kilometer. Det virtuella nätverket är ett logiskt överlägg ovanpå azures fysiska datacenternätverk. Ett virtuellt nätverk innebär inte någon specifik nätverkstopologi i datacentret.
Till exempel kan två virtuella datorer som finns i samma virtuella nätverk och undernät finnas i olika rack, rader eller till och med datacenter. De kan separeras med fötter av fiberoptisk kabel eller med kilometer fiberoptisk kabel. Den här varianten kan ge variabel svarstid (några millisekunders skillnad) mellan olika virtuella datorer.
Den geografiska placeringen av virtuella datorer och den potentiella svarstiden mellan två virtuella datorer kan påverkas av konfigurationen av tillgänglighetsuppsättningar och Tillgänglighetszoner. Men avståndet mellan datacenter i en region är regionspecifikt och påverkas främst av datacentertopologin i regionen.
Nat-portöverbelastning för källa
En distribution i Azure kan kommunicera med slutpunkter utanför Azure på det offentliga Internet och/eller i det offentliga IP-utrymmet. När en instans initierar en utgående anslutning mappar Azure dynamiskt den privata IP-adressen till en offentlig IP-adress. När Azure har skapat den här mappningen kan returtrafik för det utgående flödet också nå den privata IP-adress där flödet har sitt ursprung.
För varje utgående anslutning måste Azure Load Balancer underhålla den här mappningen under en viss tidsperiod. Med Azures multitenanta karaktär kan det vara resursintensivt att underhålla den här mappningen för varje utgående flöde för varje virtuell dator. Det finns alltså gränser som är inställda och baserade på konfigurationen av Det virtuella Azure-nätverket. Eller, för att säga det mer exakt, en virtuell Azure-dator kan bara göra ett visst antal utgående anslutningar vid en viss tidpunkt. När dessa gränser har nåtts kan den virtuella datorn inte skapa fler utgående anslutningar.
Men det här beteendet kan konfigureras. Mer information om SNAT- och SNAT-portöverbelastning finns i den här artikeln.
Mäta nätverksprestanda i Azure
Ett antal av de maximala prestandavärdena i den här artikeln är relaterade till nätverksfördröjningen/tidsåtgången (RTT) mellan två virtuella datorer. Det här avsnittet innehåller några förslag på hur du testar svarstid/RTT och hur du testar TCP-prestanda och prestanda för virtuella datornätverk. Du kan finjustera och prestandatesta TCP/IP- och nätverksvärdena som beskrevs tidigare med hjälp av de tekniker som beskrivs i det här avsnittet. Du kan ansluta värdena för svarstid, MTU, MSS och fönsterstorlek till de beräkningar som angavs tidigare och jämföra teoretiska maxvärden med faktiska värden som du ser under testningen.
Mäta tids- och paketförluster för tur och retur
TCP-prestanda är starkt beroende av RTT och paketförlust. Ping-verktyget som är tillgängligt i Windows och Linux är det enklaste sättet att mäta RTT och paketförlust. Utdata från PING visar svarstiden minimum/maximum/average mellan en källa och ett mål. Det visar också paketförlust. PING använder ICMP-protokollet som standard. Du kan använda PsPing för att testa TCP RTT. Mer information finns i PsPing.
Mäta den faktiska bandbredden för en virtuell dator
Följ den här vägledningen om du vill mäta bandbredden för virtuella Azure-datorer korrekt.
Mer information om hur du testar andra scenarier finns i följande artiklar:
Identifiera ineffektiva TCP-beteenden
I paketinsamlingar kan Azure-kunder se TCP-paket med TCP-flaggor (SACK, DUP ACK, RETRANSMIT och FAST RETRANSMIT) som kan tyda på problem med nätverksprestanda. Dessa paket anger specifikt nätverkseffektivitet som beror på paketförlust. Men paketförluster orsakas inte nödvändigtvis av prestandaproblem i Azure. Prestandaproblem kan bero på programproblem, operativsystemproblem eller andra problem som kanske inte är direkt relaterade till Azure-plattformen.
Tänk också på att vissa återöverföringar och duplicerade ACL:er är normala i ett nätverk. TCP-protokoll skapades för att vara tillförlitliga. Bevis på dessa TCP-paket i en paketinsamling tyder inte nödvändigtvis på ett systemiskt nätverksproblem, såvida de inte är överdrivna.
Dessa pakettyper tyder dock på att TCP-dataflödet inte uppnår sin maximala prestanda, av skäl som beskrivs i andra avsnitt i den här artikeln.
Nästa steg
Nu när du har lärt dig mer om TCP/IP-prestandajustering för virtuella Azure-datorer kanske du vill läsa om andra överväganden för att planera virtuella nätverk eller lära dig mer om att ansluta och konfigurera virtuella nätverk.