SSL 쓰기 버퍼를 플러시 할 수있는 방법이 있습니까

Question

하나의 SSL 서버와 상호 작용하기 위해 OpenSSL API를 사용하여 하나의 SSL 클라이언트를 작성했습니다. OpenSSL 사이트에서 필자는 쓰기 버퍼가 일부 데이터를 작성한 후에 플러시해야한다는 것을 알게되었습니다. 내 클라이언트 프로그램에서 SSL_Write 및 SSL_Read를 사용하고 있습니다. OpenSSL 사이트에서 BIO_flush (BIO *)를 사용하여 데이터를 플러시하려고 제안 했으므로 여기서 충돌이 발생합니다.

내가 사용하고 SSL 라이브러리는 어떤 다른 방법이 그래서 난 그냥 알고 싶어 :-(.. 내가 BIO_flush 버퍼를 쓰기 읽기 버퍼를 깜박 여부에 대해 확실하지 오전 여기

this site에서 가져온 여기

내 클라이언트 프로그램에 대한 세부 사항을입니까? ...는 SSL 쓰기 버퍼를 플러시. SSL_new

크레아을 사용하여 SSL 객체 (MSSL)를 만들기

1. 팅 SSL_set_bio (MSSL, mBio, mBio)를 사용하여 SSL 객체에 BIO 객체를 설정 TCP 소켓 서버 BIO 객체 (mBio) BIO_new_socket 사용하여 만들기
2. 로 만들기 연결 (socket_id을 BIO_NOCLOSE)
3. ;
4. SSL_set_fd (mSsl, socket_id)를 사용하여 소켓을 SSL 객체로 설정합니다.
5. SSL_Connect (mSsl)을 사용하여 서버와 SSL 연결하기.

위의 단계를 수행 한 후 쓰기 및 읽기를 위해 두 개의 별도 스레드를 시작합니다. 쓰기 스레드는 SSL_write를 사용하여 서버에 데이터를 쓰고 읽기 스레드는 SSL_Read를 사용하여 서버에서 데이터를 읽습니다.

SSL_Write를 사용하여 각 패킷을 쓰고 쓰는 쓰레드에서 BIO_flush (mBio)를 호출하고 있습니다.

전체 프로그램에서 직접 바이오 버퍼 플러시를 수행하기 위해이 장소에서만 mBio 개체를 사용하고 있습니다.

일부 패킷을 보내기 시작하면 BIO_flush에서 충돌하는 프로그램이 생깁니다. 덤프마다 BIO_ctrl 함수가 해당됩니다. 나는 그 이상을 얻지 못하고있다.

위의 링크를 제공하고 동일한 문제에 직면 해있는 라이브러리를 사용한 사람이 있습니까? 예인 경우 해결책을 알고 있다면 알려주십시오.

BIO_flush()를 사용하는 스레드 동기화 규칙이 있습니까? BIO_flush에 대한 호출을 의미합니다 SSL_Read는 같은 시간에 발생하지 않아야합니다 ...?

Answer 1

BIO_flush는 쓰기 데이터를 플러시하는 데 사용됩니다.

BIO 구조가 SSL_read/write 호출을 인식하지 못하기 때문에 BIO_flush와 SSL_read/write의 혼합 및 일치가 문제가됩니다.

BIO_read/write를 사용하면 더 나은 결과를 얻을 수 있습니다.

SSL_read/write를 반드시 사용해야하는 경우 BIO 사용을 피해야합니다.

이 OpenSSL 설명서의 끝 부분에있는 예제를 통해 훨씬 더 멀어 질 것이라고 생각합니다.

Simple OpenSSL Client Example

그 예를하려고 할 때 당신은 여전히 ​​충돌을 받고있는 경우, 당신은 당신이 사용하는 빌드 특정 라이브러리에 문제가있을 수 있습니다.

Answer 2

쓰기 버퍼가 쓰기 후에 플러시되어야한다는 것을 어디에서 알게 되었습니까?

나는 또한 플러시 기능을 찾고 있었지만 찾을 수 없었습니다.

나는 SSL_write를 호출 할 때마다 적어도 하나의 SSL 레코드를 생성하고 소켓으로 보낸다. 여기서 nagle 알고리즘은 잠시 동안 커널에서 버퍼를 채우고 곧바로 외부로 전송할 수있다.

따라서 SSL_write에 버퍼링이 없으므로 플러시가 필요 없습니다!

차라리 플러시 기능을 사용하고 모든 SSL 레코드를 가장자리에 채우고 싶지만 현재까지는 볼 수 없었습니다. 이제 내 자신의 버퍼링을 수행하고 가능하면 SSL_write에 대한 대규모 호출을 수행 할 계획입니다.

BTW : 방금 테스트 프로그램을 작성했습니다. 하나의 쓰기 버퍼를 보낸 다음 각 문자에 대해 SSL_write를 호출하여 다시 실행했습니다. 두 번 모두 tcpdump를 실행하고 Wireshark에서 첫 번째 실행에는 응용 프로그램 데이터 레코드가 적고 두 번째 실행에는 많은 작은 레코드가 있음을 알 수있었습니다. 그래서 나는 그것이 확실하다고 생각한다.