Số thứ tự của các tiêu đề gói TCP có bao quanh không?


16

Tôi đã tự hỏi, vì số thứ tự trong trường tiêu đề TCP được chọn ngẫu nhiên trong quá trình bắt tay và tăng dần khi các gói được trao đổi, điều gì xảy ra sau khi truyền 2 ^ 32 - init_seq_no? Số thứ tự bao quanh và trở thành 0 hoặc là giá trị ban đầu được sử dụng lại (hoặc là một kết nối mới được khởi tạo từ nơi mà trước đó dừng lại)?

Câu trả lời:


19

Nó kết thúc bằng khoảng 0. Theo RFC 793 :

Điều cần thiết là phải nhớ rằng không gian số thứ tự thực tế là hữu hạn, mặc dù rất lớn. Không gian này nằm trong khoảng từ 0 đến 2 ** 32 - 1. Vì không gian là hữu hạn, tất cả các số học xử lý số thứ tự phải được thực hiện theo modulo 2 ** 32. Số học không dấu này bảo tồn mối quan hệ của các số thứ tự khi chúng quay vòng từ 2 ** 32 - 1 đến 0 một lần nữa. Có một số điểm tinh tế đối với số học modulo máy tính, vì vậy cần hết sức thận trọng trong việc lập trình so sánh các giá trị đó. Ký hiệu "= <" có nghĩa là "nhỏ hơn hoặc bằng" (modulo 2 ** 32).


3
Mọi số nhỏ hơn hoặc bằng mọi số khác, modulo 2 ** 32 ...
user253751

2
@ user20574 Đó là lý do tại sao kích thước cửa sổ TCP không được phép tăng lên hơn 1GB và so sánh các số thứ tự cần thực hiện theo cách ngắn nhất (nghĩa là sự khác biệt phải nằm trong phạm vi -2 ^ 31 đến 2 ^ 31).
kasperd

17

Số thứ tự bao quanh và trở thành 0?

Đúng. Tất cả các chi tiết có thể được tìm thấy trong Thông số kỹ thuật TCP RFC 793 - Giao thức điều khiển truyền .


Số thứ tự

Điều cần thiết là phải nhớ rằng không gian số thứ tự thực tế là hữu hạn, mặc dù rất lớn. Không gian này dao động từ 0 đến 2 32 - 1.

Vì không gian là hữu hạn, tất cả các số học xử lý số thứ tự phải được thực hiện theo modulo 2 32 . Số học không dấu này bảo tồn mối quan hệ của các số thứ tự khi chúng quay vòng từ 2 32 - 1 đến 0 một lần nữa.

Có một số điểm tinh tế đối với số học modulo máy tính, vì vậy cần hết sức thận trọng trong việc lập trình so sánh các giá trị đó. Ký hiệu "= <" có nghĩa là "nhỏ hơn hoặc bằng" (modulo 2 32 ).

Nguồn RFC 793 - Giao thức điều khiển truyền


1
Tôi không có ý định bắn tin nhắn, nhưng "nhỏ hơn hoặc bằng (modulo N)"? Rõ ràng tác giả RFC đã bỏ lỡ "số học cho số học mô-đun máy tính".
Ben Voigt

Trong trường hợp cửa sổ tối đa sẽ nhỏ hơn 2 ^ 31 và nếu xylà loại uint32_tthì thực tế để xác định x<=ylà có nghĩa (uint32_t)(y-x) < 0x80000000.
supercat

@BenVoigt, mor có khả năng họ đã được cấp những gì sau này được mô tả trong một công cụ RFC.ietf.org/html/rfc1982
Carsten S

@Carsten đó là một số học hữu ích nhưng nó không phải là "modulo số học N"
Ben Voigt

1
@BenVoigt, ừ, sao cũng được. Btw, tôi nhận thức rõ rằng các nhóm Z / (n) không được sắp xếp, nhưng tôi cũng có khả năng diễn giải các câu trong ngữ cảnh.
Carsten S

7

Vâng, nó không bao bọc xung quanh. Bạn có thể đọc nó trên Wikipedia hoặc trên RFC1323 , trong đó cho thấy cách bảo vệ chống lại các số thứ tự được bọc.

Hãy để tôi trích dẫn:

Dấu thời gian TCP được sử dụng trong một thuật toán được gọi là Bảo vệ chống lại các số thứ tự được gói hoặc PAWS (xem RFC 1323 để biết chi tiết). PAWS được sử dụng khi cửa sổ nhận vượt qua ranh giới bao quanh số thứ tự. Trong trường hợp một gói có khả năng được truyền lại, nó trả lời câu hỏi: "Đây là số thứ tự trong 4 GB đầu tiên hay thứ hai?" Và dấu thời gian được sử dụng để phá vỡ cà vạt.

Và:

PAWS sử dụng tùy chọn Dấu thời gian TCP giống như cơ chế RTTM được mô tả trước đó và giả sử rằng mọi phân đoạn TCP nhận được (bao gồm cả phân đoạn dữ liệu và ACK) đều chứa dấu thời gian SEG.TSval có giá trị không giảm theo thời gian. Ý tưởng cơ bản là một phân đoạn có thể bị loại bỏ như một bản sao cũ nếu nó được nhận với dấu thời gian SEG.TSval ít hơn một số dấu thời gian nhận được gần đây trên kết nối này.

Trong cả cơ chế PAWS và RTTM, "dấu thời gian" là các số nguyên không dấu 32 bit trong không gian 32 bit mô-đun. Do đó, "nhỏ hơn" được định nghĩa giống như cách sử dụng cho các số thứ tự TCP và áp dụng các kỹ thuật triển khai tương tự. Nếu s và t là các giá trị dấu thời gian, s <t if 0 <(t - s) <2 ** 31, được tính theo số học 32 bit không dấu.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.