Implementacións do TCP

O Transmission Control Protocol (TCP) é unha serie de normas e recomendacións teóricas, mais que na práctica poden programarse de distintos xeitos. 
Por iso existen varias **implementacións do TCP**, cada unha coas súas vantaxes e inconvenientes. 
Para evitar a repetición de traballo é común que unhas se baseen noutras, o que leva a que tamén compartan os mesmos fallos.

## Historia 
As primeiras implementacións xurdiron nos anos 80 por parte dos sistemas BSD, 
que derivaban dos UNIX. 
Nesta época aínda se estaba desenvolvendo a historia de Internet.

miniatura|300px|dereita|Algunhas versións do BSD e características do TCP ofrecidas (en castelán)

O 4.1aBSD, publicado en xuño de 1981, xa tiña unha versión preliminar do TCP/IP, 
baseada no traballo de Bolt, Beranek e Newman (BBN) mais algo modificado. 
A versión 4.1cBSD (1982) tivo unha implementación mellor, e incluíuse no 4.2BSD (1983), 
que foi a primeira versión que se distribuíu a grande escala. 
O DARPA decidiu que sería esta versión a que ficaría no 4.3BSD (xuño de 1986); 
alén diso, nesta versión mellorouse o seu rendemento.

Do 4.3BSD deriva o 4.3BSD-Tahoe (xuño de 1988), e deste o 4.3BSD-Reno (1990), 
no camiño para a creación do 4.4BSD (1993). 
Os nomes Tahoe e Reno son os que identificarán ás implementacións do TCP destes sistemas. 
Corresponden a cidades do estado de Nevada (Estados Unidos) famosas polos seus casinos: 
Tahoe, Reno (Nevada); tamén Las Vegas serve como nome para outra versión de 1994.

Unha listaxe do nivel de implementación do TCP en cada unha destas versións é: 

* 1983: 4.2BSD: primeira versión amplamente dispoñíbel do TCP/IP 
* 1986: 4.3BSD: mellor rendemento do TCP 
* 1988: 4.3BSD-Tahoe: inicio lento (slow-start), control de conxestión (congestion avoidance), retransmisión rápida (fast retransmit) 
* 1990: 4.3BSD-Reno: recuperación rápida (fast recovery), predición de cabezallos TCP, cabezallo SLIP, compresión 
* 1993: 4.4BSD: multidifusión, modificacións para canles de alto rendemento (RFC 1323) 
* 1994: 4.4BSD-Lite

Existe pouca documentación técnica que recolla as mudanzas entre as versións. 
Nos libros de Karels e McKusick de 1986 
descríbense as mudanzas de 4.2BSD para 4.3BSD, 
e Jacobson describe en 1990 as mudanzas de 4.3BSD-Tahoe para 4.3BSD-Reno. 
(,
as máis populares son:

* Tahoe sen Fast Retransmit: inclúe inicio lento e control de conxestión 
* Tahoe: inclúe tamén retransmisión rápida 
* Reno: engade recuperación rápida a Tahoe 
* New-Reno: versión de Reno cun sistema mellorado de *recuperación rápida* 
* Reno Plus: nalgúns sistemas Solaris 
* SACK: usa confirmacións (ACK) selectivas

Ademais da Vegas, Peach, ATCP, e outras (Westwood, Hybla, ...).

No mesmo artigo descríbense as súas características, e, de entre as 6 desta lista, conclúese que New-Reno é a implementación máis fiábel.

Outro estudo si que ten en conta á Vegas, e conclúe que a Vegas é mellor 
que o resto das implementacións probadas (Tahoe, Reno, New-Reno e SACK). 

## Implementacións segundo o sistema operativo 
Cada sistema operativo mostra un comportamento distinto canto ao TCP, 
mais algúns parécense entre eles porque compartiron código 
(principalmente, o de BSD). 
Ás veces clasifícanse os sistemas segundo a implementación base á que se parece 
(Tahoe, Reno, New-Reno, Vegas etc.). 
Os que usan un código escrito desde cero son os que máis se diferencian do resto.

### BSD 
O 4.4BSD orixinal (implementación base) permite catro familias de protocolos: 
TCP/IP, Xerox Network Services (XNS), OSI, sockets IPC (UNIX domain sockets). 
En ,
que ademais cita estudos anteriores feitos sobre este código. 
Explícase tamén o funcionamento de implementacións derivadas, como a do FreeBSD, 
á hora de montar un router por software.

FreeBSD, NetBSD e OpenBSD 
son todos derivados do BSD, e por iso herdaron algúns dos seus protocolos de rede. 
Á parte destas, existen moitas máis distribucións BSD.

## Verificación e probas 
Xa que unha mala implementación do TCP pode causar conxestións, dedícase moito esforzo a estudar os problemas das implementacións existentes.
Algúns dos parámetros que se evalúan son:
* Corrección funcional: como de estritamente cumpre co estándar TCP
* Rendemento: como de rápido permite enviar datos
* Comportamento no caso de estrés: que é o que pasa cando hai moita carga

O IETF explica no RFC 2398 algunhas ferramentas que se poden usar para comprobar unha implementación do TCP.
Inclúense programas como simuladores de rede, servidores, bibliotecas, e modificacións ao núcleo dalgúns sistemas UNIX.

Un dos métodos dispoñíbeis para facer estas probas é tratar a implementación como unha *caixa negra* e estudala desde fóra, de forma activa:
primeiro execútase un procedemento que modifica o estado da rede, e logo mírase como reacciona.
A partir desta información, pódense deducir bastantes cousas, como erros de implementación, violacións do protocolo, e decisións de deseño tomadas polos implementadores.

Outra forma de verificar unha implementación de TCP é analizar trazas de paquetes, ou sexa, capturas do tráfico que se xera ao facer unha conexión.
Isto permite estudar unha implementación da que non se ten dispoñíbel o código fonte, mais precísanse moitas capturas para poder ter unha mostra representativa de todas as situacións posíbeis.

## Consecuencias 
O feito de usar unha implementación do TCP ou outra muda algunhas cousas.
Ademais de teren cadanseus erros distintos, as versións expoñen cadanseus detalles internos que poden servir para deducir información sobre o computador.

### Identificación do SO segundo a pila TCP/IP 
Debido á evolución do TCP, actualmente hai moitas versións distintas; unhas escritas desde cero e outras baseadas en implementacións anteriores mais con algunhas mudanzas.
Estas variacións entre versións fan que cada unha se comporte de xeito distinto, e isto permite poder intuír a versión que está a utilizar un computador a partir do comportamento TCP que amosa.
Aínda é posíbel facer identificación remota do sistema operativo (*fingerprinting*).

Programas como o escáner de portos nmap teñen unha base de datos coa pegada que deixa cada sistema, e poden facer a identificación automaticamente de forma activa.
Hai moita documentación sobre este tema escrita polo autor do nmap.

[miniatura|300px|dereita|[nmap identificando o sistema operativo dun Linux e un router.]]

Segundo estes documentos, as técnicas usadas para descubrir información inclúen:
* enviar un paquete FIN a un porto aberto, e comprobar se hai resposta (non debería segundo o RFC 793, pero algunhas implementacións o fan)
* encontrar patróns nos números de secuencia iniciais
* tomar mostras do campo ID do protocolo IP
* estudar os valores de tempo do TCP (*timestamp*)
* ver en que casos se activa o bit de *non fragmentación* (DF)
* valor de fiestra inicial
* valor ACK nalgúns casos especiais
* varios valores de ICMP
* tipo de servizo (ToS)
* outras opcións do TCP

En realidade, calquera comportamento que sexa distinto entre sistemas operativos serve para poder diferencialos.
TCP é un dos campos onde hai moitas diferenzas.
Pódese encontrar moitas máis técnicas e comparativas entre ferramentas no artigo que acompaña ao programa *synscan*.

## Notas