Chƣơng 1 : Tổng quan giao thứcTCP và UDP
3. Hoạt động của giao thứcTCP
5.4. Ví dụ TCP và kích thƣớccửa sổ
Hãy xem xét một ví dụ về việc chuyển giao thức TCP trong phân đoạn sau đây. Chúng tôi chỉ tập trung vào các số thứ tự TCP và kích thƣớc của những cửa sổ này:
Loại phân khúc 160.221.172.250 160.221.73.26
(tiếp theo seq.no. 17768657) Ack.no. 0
8.192 cửa sổ LEN = 0 byte
SYN-ACK Seq.no. 82980009
(tiếp theo seq.no. 82980010) Ack.no. 17768657
8.760 cửa sổ LEN = 0 byte ACK Seq.no. 17768657
(tiếp theo seq.no. 17768657) Ack.no. 82980010
8.760 cửa sổ LEN = 0 byte Seq.no. 17768657
(tiếp theo seq.no. 17768729) Ack.no. 82980010
8.760 cửa sổ
LEN = 72 byte dữ liệu
Seq.no. 82980010
Ack.no. 17768729 8.688 cửa sổ
LEN = 60 byte dữ liệu Seq.no. 17768729
(tiếp theo seq.no. 17768885) Ack.no. 82980070
8.700 cửa sổ
LEN = 156 byte của dữ liệu
Seq.no. 82980070
(tiếp theo seq.no. 82980222) Ack.no. 17768885
8.532 cửa sổ
LEN = 152 byte của dữ liệu FIN Seq.no. 17768885
(tiếp theo seq.no. 17768886) Ack.no. 82980222
8.548 cửa sổ LEN = 0 byte
FIN-ACK Seq.no. 82980222
(tiếp theo seq.no. 82980223) Ack.no. 17768886
8.532 cửa sổ LEN = 0 byte ACK Seq.no. 17768886
(tiếp theo seq.no. 17768886) Ack.no. 82980223
8.548 cửa sổ LEN = 0 byte
Giá trị của LEN là chiều dài của dữ liệu TCP đƣợc tính bằng cách trừ IP header TCP và kích cỡ từ kích thƣớc datagram IP.
1. Các phiên họp bắt đầu với trạm 160.221.172.250 khởi SYN có chứa số thứ tự
17.768.656 là ISS. Ngoài ra, các octet đầu tiên của dữ liệu chứa các số tiếp theo
trình tự 17.768.657. Có số không chỉ trong lĩnh vực số báo nhận làm điều này là không đƣợc sử dụng trong phân khúc SYN. Kích thƣớc cửa sổ của ngƣời gửi bắt đầu giảm giá là 8.192 octet nhƣ giả định là chấp nhận đƣợc để nhận.
2. Các trạm tiếp nhận gửi cả ISS của riêng mình (82980009) trong lĩnh vực dãy số và thừa nhận số thứ tự của ngƣời gửi bằng 1 (17768657) hy vọng điều này sẽ đƣợc bắt đầu từ số thứ tự của các byte dữ liệu đó sẽ đƣợc gửi tới bởi ngƣời gửi . Điều này đƣợc gọi là SYN-ACK phân đoạn. Kích thƣớc cửa sổ của ngƣời nhận bắt đầu giảm giá là 8.760.
3. Một khi SYN-ACK đã đƣợc nhận, ngƣời gửi các vấn đề một ACK thừa nhận rằng ISS bằng 1 và đặt nó trong lĩnh vực ghi nhận (82980010). Ngƣời gửi này cũng sẽ gửi cùng một dãy số mà nó đƣợc gửi trƣớc đây (17768657). Đây là phân khúc sản phẩm nào của dữ liệu và chúng tôi không muốn các buổi chỉ để giữ ramping lên các số thứ tự không cần thiết. Kích thƣớc cửa sổ của 8.760 đƣợc công nhận bởi ngƣời gửi.
4. Từ bây giờ ACK s đƣợc sử dụng cho đến trƣớc khi kết thúc phiên giao dịch này. Những ngƣời gửi ngay bây giờ bắt đầu gửi dữ liệu bằng cách ghi rõ số thứ tự
17768657 lần nữa vì đây là số thứ tự của byte đầu tiên của dữ liệu mà nó đƣợc gửi.
Một lần nữa số 82980010 xác nhận đƣợc gửi đó là số thứ tự dự kiến của byte đầu tiên của dữ liệu mà sẽ gửi cho ngƣời nhận. Trong kịch bản trên, ngƣời gửi là intitially gửi 72 byte dữ liệu trong một phân đoạn. Các quá trình phân tích mạng có thể chỉ ra con số dự kiến tiếp theo trong chuỗi các dấu vết, trong trƣờng hợp này này sẽ đƣợc 17768657 + 72 = 17.768.729. Ngƣời gửi đã đồng ý với kích thƣớc cửa sổ của 8.760 và sử dụng nó chính nó.
5. Tiếp nhận công nhận việc nhận đƣợc dữ liệu bằng cách gửi về số 17768729 trong lĩnh vực số xác nhận qua đó ghi nhận rằng các byte tiếp theo của dữ liệu đƣợc gửi đi sẽ bắt đầu với số 17768729 dãy (tiềm ẩn ở đây là sự hiểu biết rằng con số lên đến trình tự và bao gồm cả 17768728 đã đƣợc công nhận). Chú ý rằng không phải tất cả các byte cần phải đƣợc công nhận. Ngƣời nhận cũng sẽ gửi lại số thứ tự của byte đầu tiên của dữ liệu trong phân khúc của riêng mình (82980010) mà là để đƣợc gửi đi. Thu đƣợc gửi 60 byte dữ liệu. Các nhận trừ 72 byte từ kích thƣớc cửa sổ trƣớc của 8.760 và gửi 8.688 nhƣ kích thƣớc cửa sổ mới.
6. Ngƣời gửi công nhận việc nhận đƣợc dữ liệu với số 82980070 (82980010 + 60) trong lĩnh vực số xác nhận, đây là số thứ tự của byte dữ liệu tiếp theo dự kiến sẽ đƣợc nhận đƣợc từ ngƣời nhận. Những ngƣời gửi gửi 156 byte dữ liệu bắt đầu từ số thứ tự 17.768.729. Ngƣơi gƣ̉ i trừ 60 byte từ kích thƣớc cửa sổ trƣớc của 8.760 và gửi kích thƣớc mới của 8.700.
7. Tiếp nhận công nhận nhận đƣợc dữ liệu này với số 17768885 (17768729 + 156) vì nó đã mong nó, và gửi 152 byte dữ liệu bắt đầu bằng số thứ tự 82.980.070. Nhận Các trừ 156 byte từ kích thƣớc cửa sổ trƣớc đó và gửi số 8.688 kích cỡ của cửa sổ
mới 8.532.
8. Ngƣơi gƣ̉ i thừa nhận điều này với số thứ tự tiếp theo dự kiến 82980070 + 152 = 82980222 và gửi số chuỗi dự kiến 17.768.885 tại bên ngƣời nhận bởi vì vào thời điểm này ứng dụng muốn đóng phiên. Ngƣời gửi sẽ trừ 152 byte từ kích thƣớc cửa sổ trƣớc của 8.700 và gửi kích thƣớc mới của 8.548.
9. Bên nhận sẽ gửi một FIN-ACK nhận các FIN dãy số ghi nhận bằng 1-17.768.886
đó là số sẽ mong đợi trên ACK cuối cùng. Ngoài ra bên nhận sẽ gửi số chuỗi dự kiến 82.980.223. Kích thƣớc cửa sổ vẫn ở 8.532 nhƣ không có dữ liệu đã đƣợc nhận đƣợc từ FIN của ngƣời gửi.
10. Các ACK cuối cùng đƣợc gửi bởi ngƣời gửi xác nhận số chuỗi 17768886 và thừa nhận nhận đƣợc 1 byte với số ghi nhận 82.980.223. Kích thƣớc cửa sổ kết thúc tại
8.548 và các kết nối TCP là bây giờ đóng cửa.
Từ bên trên, bạn có thể thấy rằng nếu bạn có dữ liệu lƣu chuyển các ứng dụng không phải truyền trực tiếp, bạn có thể có một kịch bản mà ở đó có thể là một chuỗi dài của Acks nơi mà các số thứ tự là nhƣ nhau, các dữ liệu thu đƣợc đều có sự liên quan tới nhau. Ngoài ra, bạn có thể có một cửa sổ ứng dụng bắt đầu đƣợc kích hoạt, điều đó có nghĩa rằng trong khi chờ đợi đƣợc gửi ACK của ngƣời nhận với một kích thƣớc cửa sổ là 0 cho đến khi không gian đệm đƣợc giải phóng và ghi nhận một gửi cùng với kích thƣớc cửa sổ đẩy gói tin thêm một lần nữa, do đó cho phép ngƣời gửi để gửi dữ liệu một lần nữa và số thứ tự bắt đầu tăng trở lại.
Ví dụ trên là một ví dụ đơn giản cho việc truyền dữ liệu phiên giao dịch, tuy nhiên bạn thƣờng có nhiều phiên TCP để sắp xếp thông qua việc sử dụng các cảng khác nhau và số thứ tự, cộng với các phân đoạn trong bất kỳ một phiên họp đƣợc có thể gửi lại, gửi đi trong một hàng hoặc cửa sổ là đông lạnh do ngăn xếp bộ đệm bị đầy tất cả đều có thể làm cho nó thú vị theo dõi các số thứ tự. Hãy nhận biết rằng ACK chỉ có để xác nhận số chuỗi cuối nhận đƣợc, do đó nếu bốn phân đoạn đã đƣợc gửi trong một hàng, chỉ có một ACK đƣợc yêu cầu. Nếu số thứ tự không đến nơi thì toàn bộ phân đoạn bị mất với tất cả các byte của dữ liệu bên trong nó, cộng thêm bất kỳ phân đoạn có thể đã đƣợc gửi đi trong một hàng trƣớc khi phân đoạn bị mất.
Bạn sẽ đƣợc thông báo trong ví dụ trên là kích thƣớc cửa sổ đều giảm, điều này cho thấy rằng không có dữ liệu đã đƣợc xử lý ra khỏi ngăn xếp TCP trong thời điểm này. Trong một phiên làm việc lâu hơn, bạn sẽ nhận thấy cửa sổ tiếp tục tăng trở lại khi bộ nhớ đệm bị rỗng bởi các ứng dụng. Trong ví dụ trên các kích thƣớc cửa sổ có thể dễ dàng đƣợc thay đổi theo các gói phân đoạn khác nhau, tuy nhiên ACK không
phải lúc nào cũng làm theo và có thể đƣợc ghi nhận nhiều hơn một phân đoạn, điều này làm cho nó thêm mềm dẻo để thực hiện tiếp công việc.
Các chi tiết mô tả ở trên trƣờng hợp đơn giản của các kết nối TCP, tuy nhiên bạn có thể nhận đƣợc các tình huống phức tạp hơn, nơi kết nối đồng thời đƣợc thiết lập, hoặc các phân đoạn bị lạc hoặc bị gửi lại. Việc sử dụng khôn ngoan của RST (khởi động lại) giúp làm sạch những kết nối này lên. Bạn có thể làm theo từng bƣớc các kịch bản khác nhau trong RFC 793.