content change

src/lab1.md

@@ -48,11 +48,12 @@ w takiej kolejności. Jeśli TCP odbierze _późniejsze_ dane przed _wcześniejs
 zastosowań, gdzie _stare_ pakiety po prostu nie są nam już potrzebne (np. wideokonferencje).
 
 Z jednej strony więc rozpatrując TCP dostajemy pewne gwarancje, których sama warstwa sieciowa (w której)
-działa tu IP, nam nigdy nie da, ale tracimy kontrolę nad swoimi pakietami. Pakiety mogą być
+działa tu IP, nam nigdy nie da, ale w pewnym sensie tracimy kontrolę nad swoimi pakietami. Pakiety mogą być
 gubione i przychodzić nie po kolei - TCP ułoży je oraz ponowi transmisję za nas. Pisząc programy
 korzystające z TCP **nie wolno zakładać** że dane dojdą podzielone tak, jak zostały wysłane.
-Po prostu są to ciągi bajtów. Cena, jaką za to płacimy, to wydajność - odbiorca musi odesłać potwierdzenie
-odebrania danych.
+Po prostu są to ciągi bajtów. Odbiorca musi odesłać potwierdzenie
+odebrania danych, tak więc jest on mniej wydajny od UDP, pozwala jednak budować bardziej złożone
+protokoły nie martwiąc się o to, że pakiety nam zginą.
 
 Z tego też powodu należało wymyślić sposób, jak zaznaczyć że jeden pakiet protokołu wyższej warstwy
 (np. takie zdanie) się kończy, a drugi zaczyna. Możliwe rozwiązania są trzy: