Puncte:1

Este inutil să răspunzi la mesajele primite (pe TCP) la nivelul aplicației pentru a-i spune expeditorului că mesajele au fost primite cu succes?

drapel cn

Orice pierdere de date este detectată și corectată automat, motiv pentru care TCP se mai numește și protocol de încredere.

Cu alte cuvinte,

stratul de transport este responsabil pentru livrarea fără erori, de la un capăt la altul de date de la gazda sursă la gazda destinație.

TCP este garantat a fi un de încredere transmisie într-adevăr. Se pune o întrebare, nu-i așa redundant (sau inutil, scuze pentru limba mea slabă) să răspund la mesajele primite (care sunt transportate pe TCP) pe strat de aplicație pentru a spune expeditorului că mesajele au fost primite cu succes?

drapel ru
Luați în considerare că un client HTTP a trimis o solicitare POST către un server, va fi clientul mulțumit dacă serverul nu trimite înapoi niciun răspuns?
John avatar
drapel cn
@Chitholian Nu este un exemplu bun într-adevăr.
Puncte:9
drapel se

Nu este redundant. TCP îi pasă doar de livrarea între două sisteme, nu între două aplicații. ACK-ul este trimis odată ce datele sunt primite cu succes. Sarcina utilă a pachetelor este apoi introdusă în bufferul de socket al aplicației din partea receptorului. ACK-ul este astfel trimis înainte ca aplicația să citească sarcina utilă (din buffer-ul socketului) și în mod specific înainte de a procesa sarcina utilă, de exemplu, a făcut modificări la o bază de date pe baza sarcinii utile procesate.

Astfel, un client poate ști doar că aplicația a procesat cu succes sarcina utilă, dacă primește un fel de confirmare la nivelul aplicației.Totuși, aceasta nu trebuie să fie o recunoaștere explicită - pur și simplu trimiterea unui răspuns înapoi ar putea fi suficientă. Detaliile depind de semantica protocolului de aplicare.

John avatar
drapel cn
Înțeleg pe deplin și sunt de acord că „ACK-ul este trimis odată ce datele sunt primite cu succes”. Dar de ce vrei să spui prin „puneți în bufferul socketului aplicațiilor.„? Din câte știu eu, ACK-urile ar putea **nu** fi cunoscute de aplicații **într-adevăr**ï¼
Steffen Ullrich avatar
drapel se
@John: TCP este gestionat în mod obișnuit de nucleul sistemului de operare. Din partea aplicației există soclul unde citirea și scrierea este posibilă. Dacă datele sunt primite de nucleu, acestea sunt introduse într-un buffer de memorie asociat cu bufferul - tamponul de citire. O citire ulterioară din aplicație va prelua pur și simplu datele din acest buffer de citire. În cazul unei citiri blocate (adică aplicația care așteaptă date) datele vor fi introduse în buffer-ul de citire de către kernel și apoi aplicația blocată va fi activată astfel încât să poată citi datele din buffer.
John avatar
drapel cn
Văd. Vrei să spui că datele **altele decât** ACK sunt introduse în buffer-ul care va fi citit de aplicație mai târziu. Mulțumesc pentru clarificare.
Steffen Ullrich avatar
drapel se
@John: Da, nu am considerat ACK ca fiind *date*. Acestea sunt doar informații de transport. Am făcut-o mai clar acum, vorbind în schimb despre *sarcina utilă*.
John avatar
drapel cn
Văd, mulțumesc mult.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.