Khi sử dụng SSLStream để gửi một đoạn dữ liệu lớn (1 meg) đến một khách hàng (đã được xác thực), phân mảnh gói/không phân biệt tôi thấy là FAR lớn hơn khi sử dụng NetworkStream bình thường.Phân mảnh gói khi gửi dữ liệu qua SSLStream
Sử dụng tính năng đọc không đồng bộ trên máy khách (ví dụ: BeginRead()), ReadCallback liên tục được gọi với chính xác cùng một kích thước dữ liệu cho đến gói cuối cùng (phần còn lại của dữ liệu). Với dữ liệu tôi đang gửi (đó là tệp zip), các phân đoạn xảy ra dài 16363 byte. Note: My nhận được đệm lớn hơn nhiều so với điều này và thay đổi nó là kích thước không có tác dụng
Tôi hiểu rằng SSL mã hóa dữ liệu trong khối không lớn hơn 18kb, nhưng kể từ khi SSL ngồi trên đầu trang của TCP, tôi sẽ không nghĩ rằng số lượng các khối SSL sẽ có bất kỳ sự liên quan đến phân mảnh gói TCP?
Về cơ bản, dữ liệu được lấy khoảng 20 lần thời gian để được đọc đầy đủ của khách hàng hơn so với một NetworkStream chuẩn (cả trên localhost!)
tôi thiếu gì?
EDIT:
Tôi bắt đầu nghi ngờ rằng các nhận (hoặc gửi) kích thước bộ đệm của một SSLStream bị hạn chế. Ngay cả khi tôi sử dụng các lần đọc đồng bộ (ví dụ: SSLStream.Read()), không còn dữ liệu nào khả dụng nữa, bất kể tôi chờ bao lâu trước khi thử đọc. Đây sẽ là hành vi tương tự như thể tôi đã giới hạn bộ đệm nhận đến 16363 byte. Thiết lập SendBufferSize của NetworkStream (trên máy chủ) và ReceiveBufferSize (trên máy khách) không có hiệu lực.
Bạn đang nói về phân mảnh IP hoặc về số lần đọc bạn phải thực hiện ở phía người nhận? –
Số lần đọc được thực hiện – Ive
Bạn gửi như thế nào? Nếu bạn không sử dụng bộ đệm xung quanh các luồng SSL, bạn có thể nhận được sự bùng nổ dữ liệu trên 40x do mã hóa một byte tại một thời điểm trong bản ghi SSL của chính nó. – EJP