Nhiều quản trị viên tiếp tục duy trì - trên ServerFault và các nơi khác - ý tưởng của TCP-over-TCP tệ đến mức nào, ví dụ như trong VPN. Rằng ngay cả việc mất gói nhỏ nhất cũng sẽ khiến người ta bị suy giảm thông lượng ít nhất là nghiêm trọng nếu không phải là sự tan vỡ của TCP và do đó, TCP-over-TCP là điều tuyệt đối nên tránh. Và điều đó có lẽ đã từng là sự thật, ví dụ năm 2001 khi bài viết này được viết mà vẫn được nhắc đến.
Nhưng kể từ đó, chúng ta đã thấy những tiến bộ lớn trong công nghệ và giao thức. Ngày nay, chúng ta đã 'ACK chọn lọc' được triển khai ở hầu hết mọi nơi và luật của Moore đã cho chúng ta nhiều bộ nhớ hơn và cùng với đó là bộ đệm TCP lớn được tối ưu hóa cho các đường lên Gbit. Ngoài ra mất gói ít hơn một vấn đề ngày nay trên các liên kết không radio. Tất cả điều này sẽ làm giảm đáng kể vấn đề TCP-over-TCP, phải không?
Lưu ý rằng có các kịch bản trong thế giới thực, ví dụ: VPN dựa trên TCP dễ thực hiện và vận hành hơn các kịch bản dựa trên UDP / ESP (xem thêm bên dưới). Vì vậy, câu hỏi của tôi:
Trong trường hợp nào (mất gói liên kết & độ trễ) thì TCP-over-TCP hoạt động kém hơn đáng kể so với TCP, giả sử hỗ trợ SACK và bộ đệm TCP có kích thước vừa phải ở cả hai đầu?
Sẽ rất tuyệt vì vậy hãy xem một số phép đo cho thấy mối tương quan giữa mất / trễ kết nối gói (kết nối bên ngoài) và thông lượng / jitter (kết nối bên trong) - cho TCP-over-TCP và cho TCP. Tôi tìm thấy bài viết thú vị này , nhưng nó dường như chỉ quan tâm đến độ trễ và không giải quyết mất gói (bên ngoài).
Ngoài ra: Có các cài đặt được đề xuất (ví dụ: tùy chọn TCP, cài đặt bộ đệm, giảm MTU / MSS, v.v.) để thu hẹp khoảng cách hiệu suất giữa TCP và TCP-over-TCP không?
Cập nhật: lý do của chúng tôi.
Câu hỏi này vẫn rất phù hợp trong một số tình huống thực tế. Ví dụ: chúng tôi triển khai các thiết bị nhúng trong các tòa nhà lớn thu thập dữ liệu cảm biến và đưa nó vào nền tảng của chúng tôi thông qua VPN. Vấn đề chúng tôi đang gặp phải là tường lửa và các đường dẫn được cấu hình không đúng mà chúng tôi không thuộc quyền kiểm soát của chúng tôi, kết hợp với các bộ phận CNTT miễn cưỡng. Xem một ví dụ chi tiết được thảo luận ở đây .
Trong rất nhiều trường hợp như vậy, việc chuyển đổi từ không phải TCP sang VPN dựa trên TCP (rất dễ dàng nếu bạn sử dụng OpenVPN như chúng tôi) là một cách khắc phục nhanh cho phép chúng tôi tránh các trận chiến bằng ngón tay khó khăn. Ví dụ, thường thì cổng TCP 443 thường được cho phép (ít nhất là qua proxy) hoặc chúng tôi có thể khắc phục các sự cố Đường dẫn-MTU bằng cách giảm tùy chọn MSS của TCP.
Sẽ rất tốt nếu biết trong trường hợp nào VPN dựa trên TCP có thể được coi là một giải pháp thay thế khả thi, vì vậy chúng tôi có thể đưa ra quyết định sáng suốt vượt trội so với ưu và nhược điểm của một trong hai tùy chọn. Ví dụ: chúng tôi biết rằng TCP-VPN phù hợp với chúng tôi trên các liên kết không phải là radio, nhưng chúng tôi có một phần lớn các máy khách từ xa trên các liên kết 3G với mất gói đáng kể và độ trễ cao - TCP-VPN sẽ hoạt động ở đó như thế nào?
Tôi đã cố gắng cải thiện tiêu đề và câu hỏi trung tâm cho phù hợp; Tôi hy vọng nó có ý nghĩa.