Hora de viver é um bom indicador do número de saltos que uma mensagem sofreu.
A identificação é um bom indicador da fonte da mensagem. (Identificação = 0 sempre enviará identificação = 0).
Reconhecimento de atraso TCP: atraso entre a mensagem e a confirmação, para que a confirmação possa ser enviada junto com a próxima mensagem. Economiza largura de banda, mas causa um atraso adicional entre a mensagem e a confirmação. Especialmente se algumas mensagens estiverem faltando devido ao congestionamento da rede, a confirmação tardia pode causar atrasos desnecessários entre o reenvio de cada mensagem, especialmente para o tamanho de uma janela pequena. O
atraso da confirmação pode ser desativado pelo TCP_QUICKACK.
Confirmação seletiva de TCP. (SACK) pode ser uma atenuação do problema de atraso de confirmação causado pela perda e reenvio da mensagem tcp. Com o reconhecimento seletivo do TCP, apenas as mensagens entre o intervalo ACK e SACK estão ausentes e precisam ser reenviadas, e elas podem ser reenviadas simultaneamente sem aguardar a confirmação anterior. Esse mecanismo reduz bastante o tráfego gerado e melhora o tempo de resposta.
Cliente de handshake TCP : SYN seq = x
servidor: SYN seq = y, ack = x + 1
cliente: seq = x + 1, ack = y + 1 O
wireshark usa números de sequência relativos para facilitar a exibição da leitura da
falha no handshake:
rejeição do servidor : (tcp.flags.reset == 1) && (tcp.seq == 1) e siga
a perda de pacotes do fluxo TCP : (tcp.flags.syn == 1) && (tcp.analysis.retransmission) e siga a
sincronização do fluxo TCP ataque de inundação: envie muitas solicitações de sincronização com endereço de origem falsificado, a resposta do servidor nunca receberá confirmação, deixe a conexão meio aberta e, eventualmente, causará o esgotamento dos recursos.
wireshark's analyse -> informações de especialistas -> bate-papos mostrarão o número total de sincronizações
Nem todos os pacotes tcp resultam em um reconhecimento, o reconhecimento pode ser preguiçoso. o cliente pode enviar 1,2,3,4,5 server ack 4 implica que todos os 1-4 são recebidos.
O cliente pode enviar mensagens adicionais antes de receber confirmação, desde que a janela deslizante não esteja cheia.
O TCP é bom para transmitir grande quantidade de dados; para pequenos blocos de dados, incorre em custo adicional de handshake.
estatísticas -> resumo (mostrar velocidade de transmissão)
estatísticas -> gráfico de fluxo TCP -> gráfico de sequência TCP (mostrar alteração de velocidade)
Síndrome da janela boba e algoritmo nagle: para pacotes pequenos, se os dados anteriores não forem recebidos oportunamente, armazene em cache os dados até que o tamanho máximo do segmento seja atingido e os envie juntos. (o algoritmo combinar nagle e atrasar a confirmação podem causar transmissão lenta)
O FCS (Frame Check Sequece) é usado para verificar a sequência incorreta. O netstat -i pode ser usado para mostrar o erro do fcs.
Cliente de fechamento de TCP : FIN seq = x, ack = y
servidor: seq = y, ack = x + 1
servidor: FIN seq = y, ack = x + 1
cliente: seq = x + 1, ack = y +1
com atraso ack, ele pode combinar a mensagem 2, 3 e se tornar
cliente: FIN seq = x, ack = y
servidor: FIN seq = y, ack = x + 1
cliente: seq = x + 1, ack = y + 1
Solicitado pelo wireshark
Tamanho do pacote limitado durante a captura (pacote muito grande). pode ser definido com o
segmento anterior tcpdump -s tamanho do pacote Tcp não capturado . geralmente: próximo pacote seq = pacote anterior seq + pacote len. Se o próximo pacote seq> pacote anterior seq + pacote len, significa que alguns pacotes estão ausentes. verifique ack para verificar se há perda de pacotes ou falta de captura pelo wireshark. Se o pacote for maior que MTU, ele será descartado.
Tcp recebe segmento invisível . Somente a confirmação, mas não a mensagem original, é capturada, geralmente ocorre no início da captura.
Tcp fora de serviço . se a próxima sequência de pacotes for menor que a sequência de pacotes anterior + comprimento. Uma grande variedade de irregularidades pode causar excesso de confirmação duplicada e causar retransmitência.
Tcp dup ack . na falta de um pacote no meio da sequência, faça com que ele seja capturado várias vezes
Tcp retransmissão rápida . > = 3 tcp dup ack aciona tcp retransmissão rápida
Tcp retransmision . o último pacote de uma sequência está ausente e nenhum outro pacote aciona o dup ack. remetente aguarde o tempo limite e aciona a retransmissão tcp
Tcp zerowindow . (win = 0) O buffer de recebimento do lado do receptor está cheio.
Janela TCP cheia . dados em transmissão sem confirmação> = tamanho da janela anunciada pelo receptor (implica que o remetente não pode enviar mais dados)
Tempo de remontagem do fragmento excedido . pacote de fragmento não pode ser montado corretamente
Bytes em vôo = seq + len - ack
para detectar o congestionamento da rede, primeiro detecte a retransmissão no wireshark, encontre o pacote original, calcule os bytes em vôo. Obtenha algumas amostras e conheça o limite de congestionamento da rede.
LSO (Descarga de segmento grande)
Às vezes, não é possível obter o pacote original para uma retransmissão, devido ao LSO, se o tamanho dos dados de transmissão for maior que o MSS, em vez dos dados dos segmentos da camada TCP, os segmentos da placa de rede diretamente.
transmissão de dados lenta pode devido ao pequeno tamanho da janela de recebimento ou ao tamanho da janela de congestionamento. cwnd start lento: valor baixo e aumento rápido, prevenção de congestionamentos: cada RTT aumenta apenas um MSS. Os bytes no vôo do último pacote na janela de envio representam cwnd. cada confirmação pode aumentar cwnd em 1 MSS, a baixa frequência de confirmação pode causar um incremento lento de cwnd.
O fragmento UDP perdido pode causar o tempo de remontagem excedido. Para o TCP, apenas o reenvio de fragmento perdido é necessário, mas nem todos os fragmentos.
A fragmentação ocorre quando o tamanho dos dados> MTU (geralmente 1500) - tamanho do cabeçalho (20)
Não é fácil detectar a menor MTU ao longo do caminho, uma MTU diferente pode causar refragmentação ou descartar pacotes.
O deslocamento ID + é usado para remontar o fragmento, o último fragmento contém sinalizador (mais fragmentos = 0)
O TCP usa o MSS, que é MTU - cabeçalho IP - cabeçalho TCP - opções TCP, o UDP não possui o conceito de MSS.
O handshake TCP troca MSS, para que o cliente possa usar o MSS correto para evitar a fragmentação.
Não fragmentar sinalizador fará com que o pacote seja descartado se for menor que MTU
o firewall causado pela perda de pacotes geralmente começa com o
congestionamento da rede do handshake , a perda de pacotes se recupera após algum tempo
verificar o tamanho do pacote de perda de pacotes, pacotes grandes podem ser indicadores de problemas na MTU.
ping -f -l [tamanho] pode ser usado para detectar o menor MTU.
O handshake TCP pode enviar a escala da janela, para que possa exceder o limite imposto pelo tamanho da janela principal do tcp.
Seqüestro de HTTP: replique a solicitação http no roteador e envie uma resposta http falsificada antes da resposta verdadeira. Principais porta-chaves: 1. TTL de resposta diferente. 2. descontinuação de identificação. 3. diferença de tamanho da janela.
O número limite de HTTP 1.1 de conexões simultâneas com o servidor para 2. O
uso de vários servidores http aumenta o número de solicitações simultâneas, ao custo do início lento do tcp cwnd. Um protocolo ideal: sem aperto de mão, sem início lento, suporte à multiplexação
Retransmissão TCP:
tshark -n -q -r <nome do arquivo> -z io, stat, 0, tcp.analysis.retransmission, "tcp.analysis.retransmission e ip.src = <IP_A>", "tcp.analysis.retransmission e ip.src = <IP_B> "
wirshark -> prepare um filtro -> selecionado (gerar expressão tshark)
http://www.wireshark.org/doc/main-pages/tshark.html
atraso de transmissão longo -> aumentar o tamanho da janela -
alta taxa de perda de pacotes -> usar a escala da janela tcp, remover a limitação da janela de envio no tamanho da janela de recebimento
diminuir a taxa de envio quando o atraso da transmissão aumentar o
tamanho da janela de ajuste para diferentes conexões para obter prioridade de
uso - reconhecimento seletivo
melhorar o cnwd lento tamanho inicial (padrão 4MSS) (a retransmissão devido ao tempo limite também será redefinida para o tamanho inicial padrão do cnwd)
use timestamps tcp