Tại sao chế độ thụ động FTP sử dụng một loạt các cổng phù du trái ngược với một cổng nổi tiếng duy nhất? [đóng cửa]


9

Trong chế độ thụ động FTP, tôi đọc rằng máy chủ sẽ gửi một số cổng ngẫu nhiên đến máy khách nơi nó có thể thiết lập kênh dữ liệu.
Sau đó, khách hàng thiết lập một kênh dữ liệu từ số cổng ngẫu nhiên của nó đến số cổng này được gửi bởi máy chủ.

Câu hỏi của tôi là tại sao máy chủ gửi một số cổng ngẫu nhiên cho khách hàng? Tại sao máy khách không thể trực tiếp thiết lập kênh dữ liệu tới cổng số 20 ở phía máy chủ?


2
Tôi nghĩ rằng điều này là lạc đề.

Thật không may, các câu hỏi về các giao thức trên OSI lớp 4 không có chủ đề ở đây.
Ron Maupin

Câu trả lời:


13

Đó là cách giao thức FTP được thiết kế để hoạt động ở chế độ thụ động. Có lẽ đó không phải là một ý tưởng hay, vì tôi không nghĩ rằng mô hình này đã được lặp lại một lần nữa trong bất kỳ giao thức nào khác (và điều đó thậm chí còn đúng hơn về chế độ hoạt động FTP).


Trên cổng kết nối dữ liệu, không có giao thức. Tất cả những gì máy chủ biết - điều duy nhất mang bất kỳ thông tin nào trong kết nối đó - là số cổng bạn kết nối.

Nếu bạn kết nối với cùng một cổng mỗi lần, máy chủ sẽ không thể cho biết bạn đang kết nối với tập tin nào. Số cổng đóng vai trò là liên kết giữa yêu cầu chuyển trên kết nối điều khiển và kết nối dữ liệu - số cổng được chứa trong phản hồi của PASVlệnh.

Nếu hai máy khách yêu cầu chuyển cùng một lúc, khi máy chủ chấp nhận kết nối trên một cổng, máy chủ sẽ không thể cho biết tệp nào sẽ chuyển. Tất nhiên, máy chủ có thể sử dụng IP máy khách cho quyết định (thực tế nhiều máy chủ FTP xác thực rằng IP máy khách khớp với IP được sử dụng trên kết nối điều khiển, để bảo mật).

Nhưng điều này sẽ không làm việc cho:

  • Nhiều kết nối từ cùng một máy (hầu hết các máy khách FTP đều hỗ trợ chuyển / xếp hàng song song và bạn thực sự có thể chạy nhiều máy khách FTP khác nhau trên một máy);
  • Kết nối từ các máy khác nhau trong cùng một mạng (công ty), vì các máy có cùng IP bên ngoài.

Sao chép một phần từ câu trả lời của tôi sang Tại sao chế độ thụ động FTP yêu cầu phạm vi cổng thay vì chỉ một cổng? trên Lỗi máy chủ.


Số cổng được sử dụng ở phía máy chủ cũng có thể là 20 phải không? Trong mọi câu trả lời, số cổng ở phía máy chủ không phải là 20
Zephyr

Câu trả lời của tôi giải thích tại sao số cổng phải là duy nhất cho mỗi kết nối / chuyển. Vì vậy, nó không thể được sửa thành 20.
Martin Prikryl

Vâng, nó không thể được sửa nhưng một trong số chúng có thể là 20 phải không?
Zephyr

1
Có, nhưng tất cả các cổng khác phải cao hơn 1024. Và theo quan điểm thực tế, phạm vi cổng liền kề là tốt hơn. Hầu hết các tường lửa / NAT đều hỗ trợ các quy tắc dựa trên phạm vi. Bạn không muốn thêm một quy tắc đặc biệt cho cổng 20 bị cô lập - Ngoài ra, hầu hết các máy chủ FTP chỉ hỗ trợ phạm vi cổng liền kề.
Martin Prikryl

1
@ Zac67 không, máy khách sẽ mở một kết nối mới (ngoài kết nối điều khiển) để truy xuất tệp ở chế độ thụ động, do đó máy chủ không thể sử dụng số cổng nguồn (máy khách) để phân biệt giữa các kết nối máy khách. Ngoài ra, NAT sẽ thường quản lý cổng nguồn của máy khách (và / hoặc địa chỉ IP) khiến cho cách tiếp cận đó không thể sử dụng được trong thực tế.
jjmontes

4

Thông thường, máy chủ không gửi một cổng ngẫu nhiên mà là một cổng miễn phí từ một phạm vi / nhóm được xác định (bằng cách cài đặt) - đối với máy khách này có vẻ ngẫu nhiên. Cổng này cần được chuyển tiếp tại tường lửa yêu cầu xác định phạm vi.

Thật không may, FTP là cổ xưa. Tôi đoán, các máy chủ cổ không thể phân biệt nhiều phiên dữ liệu của khách hàng ngoại trừ theo cổng. Nói chung, tốt hơn là chuyển sang các giao thức cập nhật hơn, nơi mọi thứ được đóng gói gọn gàng trong một phiên ổ cắm duy nhất.


Vì vậy, nó có thể là 20 phải không? Trong mỗi trang web, số cổng máy chủ cho dữ liệu không phải là 20.
Zephyr

20 là cổng gửi đi từ máy chủ cho FTP đang hoạt động (không sử dụng nhiều nữa).
Zac67

Không phải các máy chủ cổ đại gặp sự cố, đó là các nhà thiết kế giao thức vẫn đang cố gắng tìm ra cách tốt nhất để thực hiện những điều phức tạp hơn phản hồi yêu cầu nguyên thủy.
Đánh 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.