[ca] Les xarxes de comunicacions han experimentat un creixement exponencial en els últims anys, el nombre de dispositius connectats a Internet no ha parat de créixer. Es gràcies a l?algorisme de control de congestió del protocol TCP que els enllaços de la xarxa no col·lapsen donat l?elevat tràfic que es pot arribar a cursar. L?estàndard d?aquest algorisme es va dissenyar l?any 1990 i s?anomena TCP Reno. L?algorisme no es va desenvolupar tenint en compte les característiques d?un enllaç satèl·lit i calen solucions per millorar el seu rendiment. Quan es volen connectar dues seus que es troben a una zona de difícil accés, una fora de l?abast de l?altre, i no existeix cobertura de dades terrestre, les xarxes satèl·lits es fan imprescindibles. L?enllaç satèl·lit es caracteritza per tenir un retard de propagació elevat, un ample de banda considerable i sofrir pèrdues originades per fenòmens atmosfèrics i radiacions còsmiques o solars que afecten el rendiment de l?algorisme de control de congestió estàndard: es degrada la taxa de transferència de dades i es presenta un problema d?equitat en compartir l?enllaç amb un altre flux. En aquest projecte s?ha dissenyat i implementat una infraestructura de baix cost on emular el comportament de l?enllaç satèl·lit fent ús de tecnologies de virtualització, aconseguint que el sistema emulat es comporti de la manera més transparent possible, caracteritzant el comportament del sistema real. La infraestructura satèl·lit virtual implementada ens permet estudiar i avaluar les alternatives existents per millorar el protocol TCP en comunicacions que fan servir un satèl·lit geoestacionari. Les solucions de millora identificades s?han dividit en mecanismes basats en característiques estàndard del protocol TCP i en les variants de l?algorisme de control de congestió TCP. Es realitza la comparativa del rendiment de l?estàndard TCP Reno amb les variants TCP Cubic, TCP Hybla, TCP Vegas i TCP Westwood. Els resultats obtinguts mostren que TCP Cubic és la variant que presenta millor eficiència però una major latència. TCP Hybla té una bona eficiència, particularment quan es transfereixen arxius d?una mida petita i la latència resulta ser menor que la de l?estàndard TCP Reno. La variant TCP Vegas és la que té una menor latència però no supera en eficiència a variants com TCP Hybla o TCP Cubic, però te un gran problema d?equitat amb d?altres variants i amb una variant de la mateixa classe. TCP Westwood a més de presentar un problema d?equitat amb una variant de la mateixa classe en determinades circumstàncies pot estimar un ample de banda més baix que el realment disponible impactant en el rendiment. La comparativa entre variants TCP en el cas d?un entorn amb pèrdues a l´enllaç satèl·lit, mostra que la millora del ràtio d?eficiència respecte l?estàndard TCP Reno és espectacular, i pot suposar un increment de fins a 40 punts percentuals quan es fa servir una variant TCP adaptada a les característiques de l?enllaç satèl·lit. S?estudia la mida òptima que ha de tenir el buffer del mòdem satèl·lit perquè l?enllaç no fluctui i es mantingui ocupat durant tota la transmissió. S?obté com a resultat que la mesura del buffer ha de ser entorn al BDP (Bandwidth Delay Product) de l?enllaç satèl·lit, mides més grans introduiran una major latència. Si no es possible controlar la mida del buffer satèl·lit l?ús de la variant TCP Vegas pot ser una alternativa. Quan no es possible canviar la variant TCP del node emissor un Performance Enhancing Proxy (PEP) pot ser la solució per millorar el rendiment del protocol TCP en l?enllaç satèl·lit. El PEP intercepta els segments i divideix la connexió establint-ne una de nova fent ús d?una altre variant TCP adaptada a les característiques de l?enllaç. S?ha estudiat el rendiment de la solució open source PEPsal en la infraestructura satèl·lit virtual desenvolupada.

[es] Las redes de comunicaciones han experimentado un crecimiento exponencial en los últimos años. El número de dispositivos conectados a Internet no ha parado de aumentar y, en el mundo digital en el que vivimos, generan un ingente tráfico de datos que colapsaría los enlaces de la red si no fuese por el mecanismo de control de congestión del protocolo TCP. El estándar de este mecanismo denominado TCP Reno fue creado en el año 1990. Cuando se quiere interconectar dos sedes remotas que se encuentran en una zona de difícil acceso o sin cobertura de datos terrestre las redes satelitales se convierten en imprescindibles, pero TCP Reno no fue diseñado pensando en un enlace satélite. Ante el retardo elevado, la alta capacidad y las pérdidas originadas por fenómenos atmosféricos y radiaciones cósmicas o solares que caracterizan este tipo de enlaces, TCP Reno sufre una degradación importante en el throughput y presenta un problema de equidad por lo que se necesitan alternativas que mejoren el rendimiento del protocolo cuando se hace uso de un satélite de comunicaciones. En este proyecto se estudian y evalúan las alternativas que pueden llegar a mejorar el desempeño del protocolo TCP en comunicaciones vía satélite geoestacionario. Para ello, se ha diseñando e implementando una infraestructura de bajo coste en la que emular el comportamiento del enlace satélite mediante la tecnología de virtualización, de forma que el sistema emulado se comporta lo más transparentemente posible, caracterizando el comportamiento del sistema real. Las soluciones de mejora identificadas se han dividido en mecanismos basados en las características estándar del protocolo TCP y en las variantes del algoritmo de control de congestión TCP. Se realiza una comparativa del estándar TCP Reno con las variantes TCP Cubic, TCP Hybla, TCP Vegas y TCP Westwood. Haciendo uso de la tecnología UML se implementan los bancos de pruebas con una infraestructura en la que emular el comportamiento del enlace satélite y se mide la evolución de la ventana de congestión para cada variante TCP evaluando su desempeño en base a su eficiencia, latencia, adaptabilidad y equidad. La comparativa muestra como TCP Cubic es la variante que presenta generalmente mayor eficiencia pero también la mayor latencia. TCP Hybla presenta una eficiencia muy buena, destacando sobre el resto en transferencias de archivos de pequeño tamaño con una latencia mejor que el estándar Reno. TCP Vegas es la variante con una menor latencia pero no supera en eficiencia a TCP Hybla y TCP Cubic. El mayor problema de TCP Vegas es su equidad con otras variantes y con otra variante afín. TCP Westwood no es equitativa con variantes afines y en algunos casos puede estimar un ancho de banda inusualmente bajo que impacte en su rendimiento. La comparativa entre variantes TCP para un entorno ruidoso del enlace satélite, muestra que la mejora del ratio de eficiencia con respecto al estándar TCP Reno es espectacular y puede suponer un incremento de 40 puntos porcentuales, si se hace uso de una variante TCP adaptada a las características del enlace satélite. Se evalúa el tamaño óptimo del búfer del módem satélite que resulta ser entorno al BDP (Bandwidth Delay Product), tamaño mínimo que asegura que el enlace satélite no fluctúa y se mantiene ocupado durante toda la transmisión. Tamaños mayores del búfer del módem satélite causan un aumento de la latencia. La variante TCP Vegas puede resultar idónea para situaciones en las que no existe control sobre el tamaño del búfer. Se estudia y evalúa el uso de la solución opensource PEPsal cuando no es posible actuar sobre la variante TCP en el emisor: Intercalar un Performance Enhancing Proxy (PEP) antes del enlace satélite provoca una mejora en el rendimiento del protocolo TCP. El PEP permite dividir la conexión, interceptar los segmentos y establecer una nueva conexión con otra variante TCP adaptada al enlace satélite y sus características.