9.2. Lagerindelade protokoll¶
Att skicka en bildruta från kameran till en server i en annan stad innebär att flera problem måste lösas samtidigt. Den elektriska signalen måste ta sig över den första kabeln. Byten på den kabeln måste hitta sin väg genom en lokal switch. Det lokala nätverket måste lämna över meddelandet till vad som än ligger mellan det och resten av internet. De paket som överlever resan måste sättas ihop igen i rätt ordning. Mottagaren måste veta vilket av sina program de ska lämnas till. Och byten i sig måste betyda något som båda ändar är överens om.
Att försöka lösa allt detta i ett enda kodblock vore ohanterligt. Standardsvaret är att dela upp arbetet i lager. Varje lager löser ett väldefinierat problem och exponerar en enkel tjänst till lagret ovanför. Ett program pratar bara någonsin med lagret direkt under sig; lagren under det är osynliga.
Varje lager i en nätverksstack löser ett problem och lämnar en ren abstraktion uppåt till nästa.¶
9.2.1. De fem lagren¶
Namnen nedan är de som resten av detta avsnitt använder. De kommer från den standardmodell som nätverk utformades kring. De exakta gränserna mellan lager är ibland luddiga, men den roll vart och ett spelar är stabil.
Fysiskt lager. Flytta bitar mellan två enheter på samma kabel eller radio. Spänningsnivåer, ljuspulser, RF-modulering. Kamerans uppgift här är mestadels att ansluta rätt kabel eller gå med i rätt trådlösa nätverk; kislet sköter resten.
Länklager. Flytta ramar (små byteklumpar) mellan två enheter som delar ett lokalt segment. Lägger till hårdvaruadresser så att varje ram kan riktas till en specifik granne. Ethernet och Wi-Fi är de två länkteknologier kameran möter i praktiken.
Nätverkslager. Flytta paket mellan vilka två enheter som helst på internet, inte bara på samma lokala segment. Lägger till en adress på mjukvarunivå som identifierar en värd oberoende av vilken kabel den sitter på, och en routing-mekanism som hoppar ett paket från ett lokalt segment till nästa tills det kommer fram. Detta är det första lagret där kamerans Python-kod börjar ha något att säga till om.
Transportlager. Sitt ovanpå paket och erbjud leverans mellan program på två värdar, inte bara värdarna själva. Två varianter är vanliga: den ena levererar en sammankopplad, ordnad ström av byte (arbetshästen för det mesta av trafiken), den andra levererar fristående meddelanden som färdas oberoende av varandra (används när låg overhead spelar större roll än garantier). Lägger till portnummer så att flera program på samma värd kan föra konversationer parallellt.
Applikationslager. Allt ovanför transport: de protokoll som ger byten mening. De som en webbläsare talar för att läsa in sidor – och de bakom nästan varje annan internettjänst som läsaren redan använder varje dag – bor här. Handledningen behandlar transport på djupet; detta lager får ett uppföljande avsnitt för sig självt.
9.2.2. Hur lagren staplas vid körning¶
När kameran skickar byte över nätverket lägger varje lager till sitt eget huvud framför datan, ungefär som att stoppa ett kuvert inuti ett annat kuvert:
Applikationens byte går in först.
Transportlagret omsluter dem med ett litet huvud som anger vilket program de tillhör (portnumret).
Nätverkslagret omsluter det med ett huvud som anger vilken värd de är avsedda för (adressen på mjukvarunivå).
Länklagret omsluter det med ett huvud som anger vilken enhet på det lokala segmentet de ska lämnas till härnäst (hårdvaruadressen).
Det fysiska lagret omvandlar hela bunten till bitar på en kabel.
I den andra änden skalar varje lager av sitt eget huvud och lämnar resten uppåt. Den mottagande applikationen får tillbaka sina byte utan att veta att nätverks-, länk- och fysiska lagren någonsin existerade.
Denna inkapsling är anledningen till att handledningen går nerifrån och upp. Att förstå vad lagret under gör får lagret ovanför att kännas oundvikligt. De två nedersta lagren behandlas på en enda sida vardera eftersom det finns nästan ingenting att konfigurera från Python. Från nätverkslagret och uppåt saktar takten ner i takt med att Pythons roll blir större.