¿Por qué necesitamos ACK en TCP mientras ya tenemos ACK en Link Layer (ex CSMA / CA)?

  1. El ACK de capa de enlace, si incluso está presente (y muchos protocolos de nivel de enlace no lo tienen en absoluto) solo le dice que un marco de nivel de enlace dado llegó a través de ONE HOP. No dice nada más.
  2. El TCP Ack, por otro lado, tiene el número de secuencia de los bytes PAYLOAD que llegaron hasta el destino, a través de todos los saltos de enlace que tomó, y posiblemente (en caso de larga distancia, comúnmente) en muchos TIPOS de saltos de nivel de enlace. En el camino, la carga útil puede haberse dividido y vuelto a colocar en diferentes números y tamaños de tramas de nivel de enlace, cada una de las cuales puede o no tener un mecanismo ACK. Esta información orientada a PAYLOAD permite que TCP ignore lo que suceda en los niveles más bajos que puedan haber sucedido y funcione como se espera, incluido el uso de esta información de número ACK / Sequ NEC para determinar si y qué bytes de carga útil deben retransmitirse, y controlar el velocidad de transmisión para intentar compartir el ancho de banda de toda la ruta de extremo a extremo de manera justa con otras secuencias TCP.

Si no tiene ACK en la capa TCP, ¿cómo se señalizarán los reconocimientos en la capa TCP?

El hecho de que el hardware haya aceptado algo no significa nada para una aplicación TCP; bien podría ser un paquete no válido o algo destinado a un puerto TCP que no está escuchando actualmente. Y hacer que las capas inferiores sean conscientes de las capas superiores es un gran no-no (para que el hardware sepa que el puerto TCP está cerrado, por ejemplo).