La lliçó anterior va acabar amb un full de ruta i una promesa: el primer pas per partir el monòlit de Quilòmetre Zero és aconseguir que dos processos parlin entre ells de manera fiable. Abans de triar un mecanisme d'alt nivell (RPC, gRPC, cues de missatges), cal entendre sobre què s'apuntalen tots ells: els protocols de xarxa. Tot el que veurem en aquest mòdul (i bona part del que veurem a la resta del curs) són bytes que viatgen per TCP o UDP, gairebé sempre embolcallats en HTTP. Si no s'entén què garanteix cada capa i què no, és impossible raonar sobre timeouts, duplicats, ordre de missatges o rendiment.

En aquesta lliçó construirem la primera versió, deliberadament primitiva, del servei inventari com un servidor TCP que respon a una ordre de text; enviarem posicions de furgoneta-3 per UDP i observarem què es perd; i farem una petició HTTP al monòlit per veure què hi ha sota un curl. Amb aquest material pràctic compararem TCP, UDP, HTTP (en les versions 1.1, 2 i 3) i MQTT, i fixarem criteris per triar entre ells.

1. Què és un protocol i per què s'organitza en capes
2. La pila TCP/IP
3. TCP: la connexió fiable i el seu preu
4. UDP: rapidesa sense garanties
5. HTTP/1.1, HTTP/2 i HTTP/3
6. Protocols lleugers: MQTT i WebSockets
7. Pràctica: inventari sobre TCP, telemetria per UDP i una petició HTTP al monòlit
8. Com triar: taula comparativa
9. Errors comuns i consells
10. Exercicis
11. Conclusió

Un protocol és un acord entre dues parts sobre tres coses: el format dels missatges (quins bytes signifiquen què), les regles d'intercanvi (qui parla primer, com es respon, què passa davant d'un error) i el significat de cada missatge. Sense un acord previ no hi ha comunicació possible: quan comandes envia bytes a inventari, tots dos han d'haver pactat d'entrada que ESTOC formatge-curat\n és una consulta i que OK 5\n n'és la resposta.

Els protocols de xarxa s'organitzen en capes perquè el problema és massa gran per resoldre'l de cop. Cada capa resol un problema concret i ofereix un servei a la capa superior, tot amagant-li els detalls de les inferiors:

• La capa d'enllaç mou trames entre dues màquines connectades físicament (Ethernet, Wi-Fi).
• La capa de xarxa (IP) mou paquets entre màquines de xarxes diferents, saltant per routers. No garanteix res: els paquets es poden perdre, duplicar o arribar desordenats.
• La capa de transport (TCP, UDP) lliura dades a un procés concret (identificat per un port) i, en el cas de TCP, hi afegeix fiabilitat i ordre.
• La capa d'aplicació (HTTP, MQTT, DNS, el protocol de gRPC...) defineix el significat dels missatges per a un ús concret.

Aquesta separació és la raó per la qual pots escriure un servidor HTTP sense saber res d'Ethernet, i també la raó per la qual les fal·làcies de la lliçó 01-04 són tan perilloses: cada capa amaga els problemes de la inferior, però no els elimina. TCP amaga que IP perd paquets a força de reintentar, i aquest reintent es tradueix en latència impredictible (fal·làcia 2).

El model TCP/IP té quatre capes (el model OSI, més acadèmic, en té set; a la pràctica es parla amb la terminologia de tots dos, i convé conèixer-ne la correspondència).

Quan comandes envia "ESTOC formatge-curat" a inventari, el missatge baixa per la pila a l'emissor (se li afegeixen capçaleres TCP, després IP, després Ethernet: encapsulació) i puja per la pila al receptor, on cada capa treu la seva capçalera. És útil visualitzar-ho:

Un detall pràctic que s'oblida sovint: un port identifica un procés, no un servei lògic. Quan inventari tingui diverses rèpliques (inv-bcn, inv-vlc), cadascuna escoltarà a la seva pròpia IP i port, i caldrà alguna cosa per sobre (DNS, un balancejador, el descobriment de serveis de Kubernetes, lliçó 07-05) perquè comandes sàpiga a quina adreçar-se.

TCP (Transmission Control Protocol) és el protocol de transport que fan servir HTTP, gRPC, AMQP, el protocol de PostgreSQL i gairebé tota la resta. Ofereix quatre garanties sobre IP, que no n'ofereix cap:

1. Connexió. Abans d'enviar dades s'estableix un canal bidireccional entre dos extrems (IP:port ↔ IP:port). Les dades pertanyen a aquesta connexió, i la connexió es tanca explícitament.
2. Fiabilitat. Cada byte enviat té un número de seqüència; el receptor confirma (ACK) el que ha rebut; el que no s'ha confirmat es retransmet. Des del punt de vista de l'aplicació, o el byte arriba, o la connexió acaba amb error.
3. Ordre. Els bytes es lliuren a l'aplicació en el mateix ordre en què es van enviar, encara que els paquets IP arribin desordenats.
4. Control de flux i de congestió. El receptor anuncia quant pot acceptar (finestra de recepció), i l'emissor redueix el ritme quan detecta pèrdues, que interpreta com a congestió de la xarxa.

TCP lliura un flux de bytes, no missatges. Si comandes fa dos send() seguits de "ESTOC formatge-curat\n" i "ESTOC tomaquet-rosa\n", el receptor els pot obtenir en un sol recv(), o en tres trossos de mida arbitrària. L'aplicació és responsable de delimitar els missatges (amb un terminador com \n, amb un prefix de longitud, o amb un format autodescriptiu). És la font d'errors més freqüent en programar amb sockets i la raó per la qual existeixen els protocols d'aplicació: HTTP fa servir capçaleres i Content-Length; gRPC fa servir un prefix de longitud de 5 bytes per missatge.

Obrir una connexió TCP requereix un intercanvi de tres missatges (SYN, SYN-ACK, ACK): un viatge d'anada i tornada complet (RTT) abans de poder enviar el primer byte útil. Si a més hi ha TLS (lliçó 06-02), s'hi afegeixen un o dos RTT més. Entre dos contenidors del mateix centre de dades l'RTT és d'uns 0,5 ms i el cost és menyspreable; entre l'app d'un repartidor amb 4G a Lleida i el servidor, l'RTT pot ser de 80-100 ms, i obrir una connexió per cada missatge és un malbaratament enorme. D'aquí neix la importància de les connexions persistents (keep-alive) i dels pools de connexions: obrir poques connexions i reutilitzar-les.

La garantia d'ordre té un preu. Si en una connexió TCP es perd el paquet número 7, TCP reté els paquets 8, 9 i 10 (que sí que han arribat) fins que arriba la retransmissió del 7, perquè ha de lliurar els bytes en ordre. Aquest fenomen s'anomena bloqueig de cap de línia (head-of-line blocking, HOL): una pèrdua endarrereix tot el que ve darrere, encara que sigui independent. Quan diverses peticions lògiques comparteixen una connexió (com fa HTTP/2), una pèrdua en la petició de l'Anna endarrereix la petició d'en Marc. Ho reprendrem en parlar d'HTTP/3.

Mai de manera immediata. Si el procés d'inventari mor netament, el sistema operatiu tanca la connexió i el client rep un error ràpid. Però si el servidor sencer s'apaga o un router deixa d'encaminar, no arriba cap paquet de tancament: el client continua esperant fins que les seves retransmissions esgoten un límit (minuts, per defecte) o fins que el mecanisme keepalive de TCP (desactivat per defecte, i amb intervals d'hores) ho detecta. Aquesta és la raó tècnica per la qual la lliçó 01-04 insistia que cap crida remota s'ha de fer sense timeout d'aplicació: TCP no ho farà per tu.

UDP (User Datagram Protocol) és el mínim que es pot posar sobre IP: hi afegeix els ports d'origen i destí i una suma de verificació, i res més. No hi ha connexió, no hi ha confirmacions, no hi ha retransmissió, no hi ha ordre, no hi ha control de flux. Cada sendto() és un datagrama independent que arriba sencer o no arriba.

Per a què serveix, doncs? Per als casos en què les garanties de TCP fan nosa:

• Quan una dada vella no val res. L'app de furgoneta-3 envia la seva posició GPS cada segon. Si es perd la posició de les 10:00:03, retransmetre-la a les 10:00:05 no aporta res: ja haurà arribat la de les 10:00:04. Amb TCP, aquesta retransmissió a més bloquejaria les posicions posteriors (HOL). Amb UDP, simplement es perd i la següent la substitueix.
• Quan la latència importa més que la completesa. Veu, vídeo en directe, jocs, telemetria.
• Quan hi ha moltíssims missatges petits i el cost de mantenir connexions seria prohibitiu (DNS fa servir UDP per això).
• Quan es vol construir un protocol de transport propi a sobre, com fa QUIC.

A Quilòmetre Zero, la telemetria de posicions és el cas clar: milers de repartidors en campanya enviant un datagrama per segon, on perdre'n un de cada cent és irrellevant. El que no s'enviaria mai per UDP és una comanda o un pagament: allà cada missatge importa. Un matís important: l'aplicació que fa servir UDP sol acabar afegint algunes de les garanties de TCP a mida (un número de seqüència per detectar desordre, per exemple), i ho veurem al codi.

HTTP és el protocol d'aplicació dominant, no només per a pàgines web, sinó com a transport d'API REST, de gRPC i, cada cop més, de gairebé qualsevol cosa (perquè travessa tallafocs i proxies sense problemes). Convé entendre'n les tres versions perquè les diferències tenen conseqüències arquitectòniques directes.

Protocol de text sobre TCP. Una petició és una línia de mètode i ruta, unes capçaleres, una línia en blanc i un cos opcional; la resposta, una línia d'estat, capçaleres i cos. És el que veuràs a l'apartat 7 en fer la petició al monòlit. Les seves limitacions:

• Una petició en vol per connexió. El client envia una petició i ha d'esperar la resposta completa abans d'enviar la següent per aquesta connexió (el pipelining existeix a l'especificació, però mai no ha funcionat bé a la pràctica). Els navegadors ho compensen obrint 6 connexions per domini; els clients d'API, amb pools.
• Capçaleres repetides i en text. Cada petició envia Host, User-Agent, Accept, cookies... sense comprimir. En una API que fa milers de crides petites, les capçaleres poden pesar més que els cossos.
• Keep-alive (connexions persistents) és el comportament per defecte i mitiga el cost del handshake, però no el problema de la serialització de peticions.

Mateix significat (mètodes, codis, capçaleres), format diferent: binari i amb multiplexació. Una única connexió TCP transporta múltiples fluxos (streams) simultanis i independents: la petició d'estoc de l'Anna i la d'en Marc viatgen intercalades a la mateixa connexió, sense esperar-se. A més, comprimeix les capçaleres (HPACK) i permet prioritzar fluxos. És la base de gRPC (lliçó 02-03) precisament per la multiplexació i perquè els fluxos permeten streaming en totes dues direccions.

El seu punt feble és el que ja coneixem: com que tots els fluxos comparteixen una connexió TCP, el bloqueig de cap de línia de TCP els afecta tots. En xarxes amb pèrdues (mòbils), HTTP/2 pot rendir pitjor que HTTP/1.1 amb diverses connexions.

HTTP/3 resol aquest problema canviant el transport: en lloc de TCP fa servir QUIC, un protocol construït sobre UDP que reimplementa fiabilitat, ordre i control de congestió, però per flux, no per connexió. Si es perd un paquet del flux de l'Anna, només s'endarrereix el flux de l'Anna. QUIC a més integra TLS 1.3 al handshake (una connexió segura en 1 RTT, o 0 RTT si es reprèn) i sobreviu a canvis d'IP (la furgoneta que passa de Wi-Fi a 4G manté la connexió). Està desplegat als grans navegadors i CDN; en la comunicació entre serveis dins d'un centre de dades el seu avantatge és menor, perquè allà gairebé no hi ha pèrdues.

Hi ha escenaris en què HTTP és massa pesant o el seu model petició-resposta no hi encaixa.

MQTT és un protocol de publicació/subscripció dissenyat per a dispositius amb recursos limitats i xarxes poc fiables (el seu origen és a la telemetria d'oleoductes per satèl·lit). Un broker central rep missatges publicats en tòpics jeràrquics (km0/repartiment/furgoneta-3/posicio) i els reenvia a qui s'hi hagi subscrit (amb comodins: km0/repartiment/+/posicio). Les seves capçaleres ocupen 2 bytes, manté una única connexió TCP persistent (de manera que un missatge no paga handshake), defineix tres nivells de qualitat de servei (QoS 0: com a molt una vegada; QoS 1: almenys una vegada; QoS 2: exactament una vegada, amb un intercanvi de quatre missatges) i inclou el concepte de last will, un missatge que el broker publica si el dispositiu es desconnecta bruscament. Per a l'app dels repartidors és una alternativa seriosa a UDP cru: paga una mica més de bytes a canvi de travessar qualsevol xarxa mòbil i de tenir un broker que reparteix les posicions. Aquí només el presentem; el disseny d'un sistema de missatgeria en temps real amb MQTT i la propagació fins al mapa de la clienta es desenvolupa a la lliçó 08-02.

WebSockets converteix una connexió HTTP en un canal bidireccional persistent entre navegador i servidor, perquè el servidor pugui enviar sense que el client pregunti. És el que farà servir la pantalla de seguiment de l'Anna per veure moure's furgoneta-3 sense recarregar. També es desenvolupa a la lliçó 08-02; aquí n'hi ha prou de saber que existeix, que va sobre TCP i que comença com una petició HTTP normal amb la capçalera Upgrade: websocket.

Tocarem les tres coses amb la biblioteca estàndard de Python. L'objectiu no és escriure codi de producció (per a això hi ha les lliçons següents), sinó veure amb les mans què fa cada protocol. Tot el codi va a km0/serveis/, que fins ara era buida.

Primera versió del servei inventari extret del monòlit: un servidor que accepta connexions i respon a l'ordre ESTOC <producte>. Definim un protocol d'aplicació mínim: missatges de text UTF-8 acabats en \n; respostes OK <unitats> o ERR <motiu>.

Explicació de les parts clau:

• socket.AF_INET, socket.SOCK_STREAM vol dir "IPv4, TCP". Amb SOCK_DGRAM seria UDP.
• bind associa el socket a una adreça i un port; listen el posa en mode servidor; accept bloqueja fins que un client completa el handshake i retorna un socket nou dedicat a aquesta connexió. El socket original continua escoltant.
• Cada connexió s'atén en un fil, perquè recv bloqueja: si atenguéssim els clients en sèrie, el segon esperaria que el primer es desconnectés. A la lliçó 01-02 vam veure l'alternativa amb asyncio; aquí fem servir fils per simplicitat.
• llegir_linia és la part més important de tot el fitxer. Acumula bytes fins a veure el terminador. Si l'elimines i confies que "un recv = un missatge", el servidor funcionarà a les teves proves locals i fallarà en producció quan la xarxa fragmenti un missatge o n'ajunti dos.
• sendall (i no send) garanteix que s'envien tots els bytes; send pot enviar-ne només una part i retornar quants n'ha enviat.

Sortida esperada:

Fixa't en dues coses. Primera: la connexió s'obre una vegada i es fa servir per a les tres consultes (keep-alive fet a mà); obrir-la a cada consulta triplicaria els handshakes. Segona: el buffer del client conserva els bytes sobrants d'un recv, per si ha arribat part de la resposta següent. Prova d'aturar el servidor amb Ctrl+C mentre el client espera: veuràs un ConnectionError immediat perquè el sistema operatiu ha tancat la connexió. Ara prova de bloquejar el port amb un tallafocs o de desconnectar la xarxa: el client no veurà res fins que salti el timeout de 2 segons. És la diferència entre una fallada crash neta i una omissió (lliçó 01-02).

Ara l'app del repartidor. Envia un datagrama JSON per segon amb la seva posició i un número de seqüència. Per simular una xarxa mòbil, l'emissor "perd" un 10 % dels datagrames abans d'enviar-los.

I el receptor a repartiment, que detecta forats a la seqüència i descarta posicions que arriben tard:

Punts importants:

• No hi ha listen, accept ni connect. recvfrom retorna un datagrama complet i l'adreça de qui l'ha enviat. A diferència de TCP, aquí sí que hi ha missatges amb límits: no cal llegir_linia.
• El número de seqüència l'afegim nosaltres: UDP no el dona. Amb ell detectem pèrdues i desordre, i decidim què fer (ignorar la pèrdua i descartar el que arriba tard, que és la política correcta per a posicions). Estem reconstruint part de TCP, la part que ens interessa, sense pagar per la que no.
• El datagrama de furgoneta-3 fa uns 100 bytes. Per TCP+HTTP/1.1, amb capçaleres, passaria de 300, i cada enviament nou des d'una connexió tancada afegiria un handshake. Per MQTT (apartat 6) serien uns 110 bytes sobre una connexió ja oberta: un compromís intermedi que veurem a 08-02.

Per acabar, parlem amb el monòlit que vam deixar engegat a 01-06, però mirant el que curl amaga.

El que viatja per la connexió TCP cap al port 8000 és exactament aquest text (pots veure'l amb curl -v http://localhost:8000/salut o amb nc localhost 8000 escrivint-lo a mà):

I la resposta:

Fixa't en Content-Length: és la manera com HTTP/1.1 resol el problema de delimitar missatges sobre el flux de bytes de TCP (el mateix que vam resoldre amb \n a 7.1). I fixa't que, comparat amb el nostre protocol de text, HTTP afegeix capçaleres que aquí ocupen més que la dada útil: és el preu de la interoperabilitat universal. Per a una crida interna entre comandes i inventari que es repeteixi 1.200 vegades per segon (lliçó 01-03), aquest preu pesa, i és una de les raons per les quals la lliçó 02-03 farà servir gRPC sobre HTTP/2 amb cossos binaris.

Criteris de tria, per ordre d'importància:

1. Cada missatge importa? Si és que sí, descarta UDP i MQTT QoS 0.
2. És petició-resposta o és un flux d'esdeveniments? Petició-resposta → HTTP/gRPC (02-02, 02-03). Flux cap a molts interessats → missatgeria (02-04) o MQTT.
3. Qui hi ha a l'altra banda? Un navegador o un tercer → HTTP. Un servei propi → gRPC. Un dispositiu amb bateria i 4G → MQTT.
4. Quants missatges per segon i de quina mida? A partir de milers per segon amb cossos petits, la sobrecàrrega d'HTTP/1.1 en text es nota; HTTP/2 binari o MQTT la redueixen.
5. Només llavors mira el rendiment brut. Gairebé mai és el factor decisiu i gairebé sempre és el primer que es discuteix.

• Suposar que un recv retorna un missatge. És l'error número u amb TCP. Funciona en local i falla en producció. Delimita sempre (terminador, prefix de longitud o format autodescriptiu) o fes servir un protocol d'aplicació que ho faci per tu.
• Confiar que TCP detectarà que el servidor ha mort. Només ho detecta si el procés tanca la connexió. Davant d'un servidor apagat o una xarxa tallada, el teu client esperarà minuts sense timeout d'aplicació.
• Obrir una connexió per petició. Cada handshake costa un RTT (més amb TLS). Reutilitza connexions: pools als clients HTTP, canals persistents a gRPC, una connexió per procés a MQTT.
• Fer servir UDP "perquè és més ràpid" per a dades que importen. Una comanda perduda no és més ràpida, és una comanda perduda. UDP és per a dades que caduquen.
• Afegir a UDP tota la fiabilitat de TCP a mà. Si acabes implementant retransmissions, ordre i control de flux, fes servir TCP (o QUIC). UDP només compensa si necessites menys garanties.
• Ignorar la mida de les capçaleres HTTP. En crides internes molt freqüents, mesurar bytes per petició revela sorpreses. HTTP/2 i els cossos binaris existeixen per això.
• Consell: aprèn a fer servir curl -v, nc (netcat) i tcpdump/Wireshark. Veure els bytes reals que viatgen resol en minuts discussions que en abstracte duren hores.
• Consell: documenta el protocol d'aplicació encara que sigui de text i de tres línies, com hem fet amb ESTOC/OK/ERR. El dia que un altre equip escrigui un client, ho agrairà; i el dia que el vulguis canviar, sabràs què es trenca.

Afegeix al servidor TCP l'ordre RESERVAR <producte> <quantitat>, que descompti estoc si n'hi ha prou i respongui OK <restant>, o ERR estoc insuficient en cas contrari. Tingues en compte que diversos fils poden reservar alhora el mateix producte (recorda l'últim formatge de l'Anna i en Marc, lliçó 01-05). Després, des del client, llança 4 reserves de 2 unitats de formatge-curat des de 4 fils simultanis i comprova que l'estoc mai no queda negatiu.

Modifica tcp_client.py perquè enviï les tres ordres ESTOC de cop amb un únic sendall (concatenades amb \n) i després llegeixi les tres respostes. Comprova si el servidor les processa correctament quan arriben juntes i explica per què, i raona què passaria si llegir_linia s'hagués escrit com return conn.recv(1024).decode().strip().

Per a cada flux de Quilòmetre Zero indica quin protocol de transport/aplicació faries servir (TCP cru, UDP, HTTP/1.1, HTTP/2, MQTT) i justifica-ho amb els criteris de l'apartat 8:

1. L'app de la Llúcia consulta el catàleg de la Formatgeria Montblanc.
2. comandes consulta l'estoc a inventari 1.200 vegades per segon en campanya.
3. furgoneta-3 envia la seva posició cada segon mentre travessa zones amb cobertura intermitent entre Lleida i Tarragona.
4. Un productor puja 40 fotos dels seus productes des de la seva oficina.
5. Un sensor de temperatura de la cambra frigorífica del Celler Roure Alt informa cada minut, amb bateria.

Solució 1:

La clau és que la comprovació i el descompte passen dins del mateix with cadenat. Si comprovessis fora del cadenat i descomptessis a dins, dos fils podrien veure "en queden 5", i tots dos descomptar-ne 2... i després un tercer i un quart també: l'estoc quedaria en -3. Amb 4 reserves concurrents de 2 unitats sobre 5, exactament dues tindran èxit (restant 3, després 1) i dues rebran ERR estoc insuficient. Client de prova:

Fixa't que, en un sol procés, el cadenat resol el problema; quan hi hagi rèpliques inv-bcn i inv-vlc, cap cadenat en memòria no servirà: aquest és el problema del Mòdul 3.

Solució 2:

Funciona perquè llegir_linia del servidor acumula fins al primer \n i... aquí hi ha una trampa: tal com està escrita, llegir_linia comprova dades.endswith(b"\n"), i si les tres ordres arriben en un sol recv, dades acaba en \n i conté tres línies; processar veurà "ESTOC formatge-curat\nESTOC tomaquet-rosa\nESTOC pernil" i respondrà ERR ordre no reconeguda una sola vegada, deixant el client esperant dues respostes que no arribaran mai (fins al timeout). La versió correcta del servidor ha de conservar un buffer per connexió i extreure'n línies amb partition, exactament com fa el client. És un exemple perfecte que "funciona a les meves proves" no vol dir "gestiona bé el flux de bytes". Amb la versió ingènua conn.recv(1024).decode().strip(), a més, una ordre que arribés partida en dos recv produiria dos errors ERR ordre no reconeguda i cap resultat.

Solució 3:

1. HTTP (1.1 o 2, segons el client): petició-resposta, client extern (app mòbil o navegador), interoperabilitat i memòria cau d'HTTP. Amb una CDN al davant, HTTP/3 millora l'experiència mòbil.
2. HTTP/2 (gRPC): cada missatge importa (descarta UDP), petició-resposta síncrona (descarta missatgeria), servei propi, volum alt amb missatges petits (la multiplexació i el format binari redueixen la sobrecàrrega). Lliçó 02-03.
3. MQTT (o UDP si la xarxa fos pròpia): les dades caduquen (una posició vella no val res), xarxa mòbil amb pèrdues, dispositiu amb bateria. MQTT amb QoS 0 dona pràcticament l'eficiència d'UDP, però manté una connexió que travessa les xarxes dels operadors mòbils i es reconnecta sola; i el broker reparteix les posicions a qui les necessiti (08-02).
4. HTTP: cada foto importa (res d'UDP), és una transferència petició-resposta, va des d'un navegador; HTTP/2 permet pujar les 40 en paral·lel per una sola connexió.
5. MQTT amb QoS 1: dispositiu restringit, xarxa possiblement inestable, missatges petits i infreqüents en què sí que importa que arribin (una temperatura fora de rang és una alerta). El last will avisaria si el sensor es desconnecta.

Aquesta lliçó ha baixat fins als fonaments sobre els quals s'apuntala tota la resta. Hem vist que un protocol és un acord de format, regles i significat, i que la pila TCP/IP reparteix el problema en capes que amaguen, però no eliminen, les fallades de la capa inferior. TCP ens dona connexió, fiabilitat, ordre i control de flux a canvi del handshake, del bloqueig de cap de línia i d'una detecció de fallades que mai no és immediata; UDP ens treu tot això i per això resulta ideal per a les posicions de furgoneta-3, on una dada vella no val res. HTTP/1.1 és text i una petició per connexió; HTTP/2 multiplexa fluxos sobre una connexió binària i és la base de gRPC; HTTP/3 s'apuntala en QUIC sobre UDP per eliminar el bloqueig de cap de línia. MQTT i WebSockets queden presentats i remesos a la lliçó 08-02. Amb el codi hem comprovat que TCP és un flux de bytes que exigeix delimitar missatges, que un client sense timeout es penja davant d'un servidor que desapareix sense tancar, i que les capçaleres HTTP poden pesar més que la dada.

El servidor TCP d'inventari amb el seu protocol ESTOC/OK/ERR funciona, però és incòmode: cada operació nova exigeix inventar un format, escriure un parser a tots dos extrems i traduir errors a mà. El que voldríem és escriure inventari.consultar_estoc("formatge-curat") al codi de comandes i que algú s'encarregués de convertir-ho en bytes, enviar-ho, esperar la resposta i retornar-la com un valor de Python. Aquesta idea, amb els seus avantatges i els seus paranys, és el tema de la lliçó següent: RPC i RMI.