2024.01.17.(수) 4회 차 모각코 정리

1. 데이터 송, 수신 동작의 개요

데이터 송, 수신은 OS 내부에 있는 프로토콜 스택에 의뢰하여 진행

마찬가지로 Socket 라이브러리를 사용

하나의 함수만 호출하는 것이 아닌 여러 함수를 순서대로 호출하여 진행

소켓 : 통로의 출입구

파이프는 원래 존재하는 것처럼 보이지만 송, 수신 동작 이전에 연결 동작이 필요함

데이터 송, 수신 단계

1. 소켓 만들기(보통 서버 측에서 만듦)
2. 서버측의 소켓에 파이프 연결(접속)
3. 데이터 송, 수신
4. 파이프 분리 후 소켓 말소(연결 끊기)

파이프 분리는 어느 쪽에서 분리해도 상관없음. 보통은 서버 측에서 파이프 분리

위의 모든 과정은 OS 내부의 프로토콜 스택이 실행

2. 소켓의 작성 단계, 3. 파이프를 연결하는 접속 단계, 4. 메시지를 주고받는 송, 수신 단계, 5. 연결 끊기 단계에서 송, 수신이 종료된다

1) 소켓 생성(feat. 디스크립터)

Socket 라이브러리의 socket()을 호출하여 소켓을 생성

리졸버처럼 socket 내부로 제어가 넘어가서 소켓을 만들고 다시 애플리케이션으로 제어가 돌아옴

socket() 호출을 통해 디스크립터를 반환받음

• 디스크립터소켓의 식별을 위한 번호표라고 생각하면 편함
• 소켓을 식별하기 위해 사용하는 것, 하나의 컴퓨터 내부에서 사용되며 포트번호와 구별됨

2) 생성한 소켓을 프로토콜 스택에 의뢰하여 서버에 접근

Socket 라이브러리의 connect()를 통해 의뢰

파라미터로는 디스크립터, 서버의 IP 주소와 포트 번호가 사용

서버의 IP 주소로 컴퓨터를 찾고, 포트 번호로 외부에서 컴퓨터의 어떤 소켓으로 접속해야하는지 확인하여 접근

그리고 디스크립터를 통해 서버 내부에서 소켓을 찾아 접속

이로써 데이터 송, 수신이 가능한 상태가 됨

• 디스크립터와 포트 번호가 분리되어 있는 이유

디스크립터 : 애플리케이션이 소켓을 식별하는 것 IP 주소와 포트 번호 : 클라이언트와 서버 간에 상대의 소켓을 식별하는 것

디스크립터는 소켓을 만들도록 의뢰한 애플리케이션에 주는 것이고, 접속 상대에게 주는 것이 아님. 따라서 접속 상대는 어떤 소켓에 접속해야할지 모르므로 포트 번호를 통해 접근해야함

• 포트 번호는 어떻게 지정되나?

서버 측의 포트 번호는 애플리케이션의 종류에 따라 미리 결정된 값을 사용한다는 규칙이 존재 웹은 80, 메일은 25 등으로 정해진 값을 사용

3) 데이터 송, 수신

• 송신 과정

Socket 라이브러리의 write()를 통해 데이터를 송신

파라미터로는 디스크립터, 송신 데이터, 송신 데이터의 길이가 필요함

프로토콜 스택이 데이터를 서버로 송신

내부적으로는 디스크립터가 소켓을 지정하여 그곳으로 데이터를 송신

이후 서버는 데이터를 받고 적절한 처리를 통해 응답 메시지를 반송

• 수신 과정

Socket 라이브러리의 read()를 통해 데이터를 수신

파라미터로는 디스크립터, 수신 버퍼가 사용됨

수신 버퍼는 응답 메시지를 받아서 저장하는 공간

4) 연결 끊기

Socket 라이브러리의 close()를 통해 연결을 끊음

연결 끊기를 시도하면 소켓 사이를 연결한 파이프가 분리되고 소켓도 말소됨

1. 웹 서버 측에서 close를 호출하여 연결을 끊음
2. 클라이언트에 전달되어 마찬가지로 소켓 연결을 끊음
3. 브라우저가 read로 수신 동작을 의뢰하면, 데이터를 읽은 후 송, 수신이 완료되어 연결이 끊겼다는 사실을 브라우저에 통지
4. 브라우저에서도 close를 호출하여 연결 끊기 단계로 돌입

HTTP 프로토콜에서는 HTML 문서나 영상 데이터를 각각 별도로 취급하여 1개의 데이터 당 위와 같은 과정을 반복했음

하지만 이 방법이 비효율적임을 감안하여 HTTP 1.1 버전부터는 복수의 요청, 응답을 주고받는 방법이 마련됨

1. 데이터 송, 수신 동작의 개요

데이터 송, 수신은 OS 내부에 있는 프로토콜 스택에 의뢰하여 진행

마찬가지로 Socket 라이브러리를 사용

하나의 함수만 호출하는 것이 아닌 여러 함수를 순서대로 호출하여 진행

소켓 : 통로의 출입구

파이프는 원래 존재하는 것처럼 보이지만 송, 수신 동작 이전에 연결 동작이 필요함

데이터 송, 수신 단계

1. 소켓 만들기(보통 서버 측에서 만듦)
2. 서버측의 소켓에 파이프 연결(접속)
3. 데이터 송, 수신
4. 파이프 분리 후 소켓 말소(연결 끊기)

파이프 분리는 어느 쪽에서 분리해도 상관없음. 보통은 서버 측에서 파이프 분리

위의 모든 과정은 OS 내부의 프로토콜 스택이 실행

2. 소켓의 작성 단계, 3. 파이프를 연결하는 접속 단계, 4. 메시지를 주고받는 송, 수신 단계, 5. 연결 끊기 단계에서 송, 수신이 종료된다

1) 소켓 생성(feat. 디스크립터)

Socket 라이브러리의 socket()을 호출하여 소켓을 생성

리졸버처럼 socket 내부로 제어가 넘어가서 소켓을 만들고 다시 애플리케이션으로 제어가 돌아옴

socket() 호출을 통해 디스크립터를 반환받음

• 디스크립터소켓의 식별을 위한 번호표라고 생각하면 편함
• 소켓을 식별하기 위해 사용하는 것, 하나의 컴퓨터 내부에서 사용되며 포트번호와 구별됨

2) 생성한 소켓을 프로토콜 스택에 의뢰하여 서버에 접근

Socket 라이브러리의 connect()를 통해 의뢰

파라미터로는 디스크립터, 서버의 IP 주소와 포트 번호가 사용

서버의 IP 주소로 컴퓨터를 찾고, 포트 번호로 외부에서 컴퓨터의 어떤 소켓으로 접속해야하는지 확인하여 접근

그리고 디스크립터를 통해 서버 내부에서 소켓을 찾아 접속

이로써 데이터 송, 수신이 가능한 상태가 됨

• 디스크립터와 포트 번호가 분리되어 있는 이유

디스크립터 : 애플리케이션이 소켓을 식별하는 것 IP 주소와 포트 번호 : 클라이언트와 서버 간에 상대의 소켓을 식별하는 것

디스크립터는 소켓을 만들도록 의뢰한 애플리케이션에 주는 것이고, 접속 상대에게 주는 것이 아님. 따라서 접속 상대는 어떤 소켓에 접속해야할지 모르므로 포트 번호를 통해 접근해야함

• 포트 번호는 어떻게 지정되나?

서버 측의 포트 번호는 애플리케이션의 종류에 따라 미리 결정된 값을 사용한다는 규칙이 존재 웹은 80, 메일은 25 등으로 정해진 값을 사용

3) 데이터 송, 수신

• 송신 과정

Socket 라이브러리의 write()를 통해 데이터를 송신

파라미터로는 디스크립터, 송신 데이터, 송신 데이터의 길이가 필요함

프로토콜 스택이 데이터를 서버로 송신

내부적으로는 디스크립터가 소켓을 지정하여 그곳으로 데이터를 송신

이후 서버는 데이터를 받고 적절한 처리를 통해 응답 메시지를 반송

• 수신 과정

Socket 라이브러리의 read()를 통해 데이터를 수신

파라미터로는 디스크립터, 수신 버퍼가 사용됨

수신 버퍼는 응답 메시지를 받아서 저장하는 공간

4) 연결 끊기

Socket 라이브러리의 close()를 통해 연결을 끊음

연결 끊기를 시도하면 소켓 사이를 연결한 파이프가 분리되고 소켓도 말소됨

1. 웹 서버 측에서 close를 호출하여 연결을 끊음
2. 클라이언트에 전달되어 마찬가지로 소켓 연결을 끊음
3. 브라우저가 read로 수신 동작을 의뢰하면, 데이터를 읽은 후 송, 수신이 완료되어 연결이 끊겼다는 사실을 브라우저에 통지
4. 브라우저에서도 close를 호출하여 연결 끊기 단계로 돌입

HTTP 프로토콜에서는 HTML 문서나 영상 데이터를 각각 별도로 취급하여 1개의 데이터 당 위와 같은 과정을 반복했음

하지만 이 방법이 비효율적임을 감안하여 HTTP 1.1 버전부터는 복수의 요청, 응답을 주고받는 방법이 마련됨