본문 바로가기
개발공부 개발새발/Network

Network ) 서버 송수신 동작과 응답

by 휴일이 2023. 8. 4.

클라이언트 vs 서버

공통

  • 네트워크
    • LAN 어댑터, 프로토콜 스택, Socket 라이브러리 등…

차이

  • 서머 머신
  • 하드웨어, OS
  • 접속 동작 (Socket 라이브러리 사용)
    • 클라이언트 - 접속 동작 수행
    • 서버 - 기다림
  • 서버 애플리케이션은 다수의 클라이언트 PC 와 대화함

서버 접속

서버는 보통 클라이언트가 접속할 때마다 새로 서버 프로그램을 작동시켜 1 : 1 로 대화한다.

  • 멀티태스크
    • 복수의 태스크(프로그램) 동시에 실행
  • 멀티스레드
    • 복수의 스레드 동시에 실행

단점 → 클라이언트가 접속했을 때 새로 프로그램을 기동하니 시간이 걸리고, 응답 시간이 추가로 소요된다.

접속하는 쪽 _ 클라이언트

  1. 소켓을 만든다. (소켓 작성 단계)
  2. 서버측의 소켓과 파이프로 연결. (접속 단계)
  3. 데이터를 송수신 (송수신 단계)
  4. 파이프를 분리하고 소켓을 말소한다. (연결 끊기 단계)

접속을 기다리는 쪽 _ 서버

  1. 소켓을 만든다. (소켓 작성 단계)
  2. 소켓을 접속 대기 상태로 만든다. (접속 대기 상태)
    1. 접속을 접수한다. (접속 접수 단계)
  3. 데이터를 송수신 한다. (송수신 단계)
  4. 파이프를 분리하고 소켓을 말소한다. (연결 끊기 단계)

→ 접속 대기, 접속 접수 단계가 추가된다.

서버 측의 구체적인 접속 동작

  1. socket 호출, 소켓 만든다.
  2. bind 호출, 소켓에 포트 번호 기록.
  3. listen 호출, 소켓 접속하기를 기다리는 상태라는 제어 정보 기록.
  4. accept 호출, 접속 접수 (접속 대기인 상태로 계속 존재)
    1. 실행 시점에 보통 서버측은 패킷을 기다리는 상태가 되고, 애플리케이션은 쉬는 상태가 된다.
  5. 애플리케이션에서 접속 패킷이 도착하면 응답 패킷 반송, 접속 접수 동작 실행.
  6. 접속 대기 소켓을 복사하여 새로운 소켓 만들기.
    1. 새로 만든 소켓에도 접속 대기 소켓과 같은 서버 포트 번호를 넣는 동시에 서버 IP, 클라이언트 IP 주소, 클라이언트 포트 번호를 작성하여 중복을 방지한다.
  7. 접속 상대의 정보를 비롯한 제어 정보를 새 소켓에 기록.

<aside> ✅ 소켓을 식별하기 위해 디스크립터를 사용하는 이유

  • 접속 대기 소켓에는 클라이언트측의 IP 주소와 포트 번호가 기록되어 있지 않다.
  • 디스크립터라는 한 개의 정보로 식별하는 것이 간단하다.

</aside>

서버 수신

패킷의 신호를 LAN 어댑터에서 수신하고 디지털 데이터로 바꾸는 부분부터 시작된다.

  1. 프리앰블 부분에서 클록 추출.
  2. 클록 위치에서 신호 변화 방향을 조사.
  3. 패킷 맨 마지막에 있는 FCS(프레임 체크 시퀀스)를 이용해 오류 유무 검사.
  4. MAC 헤더에 있는 수신처 MAC 주소를 조사하여 패킷이 자신을 수신처로 하여 보낸 것인지 판단.
  5. LAN 어댑터 내부 버퍼 메모리에 저장.
    1. —여기까지는 MAC 부분이 실행
  6. 인터럽트를 사용하여 LAN 어댑터에서 CPU 로 패킷 도착을 알림.
  7. CPU 가 실행하고 있던 작업을 중단하고 LAN 드라이버로 실행을 전환.
  8. LAN 드라이버가 동작하기 시작하여 LAN 어댑터의 버퍼 메모리에서 수신한 패킷을 추출.
  9. MAC 헤더의 타입 필드의 값에 따라 프로토콜 판별, 프로토콜을 처리하는 소프트웨어 호출
  10. TCP/IP 프로토콜 스택을 호출하고 패킷을 건네줌.
    1. —LAN 드라이버가 실행
  11. 프로토콜 스택에 패킷이 전달되면 IP 담당 부분이 동작하여 IP 헤더 점검, 자기 것인지 검사
  12. 조각 나누기에 의해 패킷이 분할 되었는지 조사
    1. 분할된 게 있다면 조각이 전부 도착한 시점에 패킷 조각 조립, 복원
  13. IP 헤더의 프로토콜 번호를 조사해 해당 담당 부분에 패킷 건네줌 (TCP , UDP)
    1. —프로토콜 스택이 실행

TCP 가 접속 패킷 수신

  1. 패킷 수신처 포트 번호를 조사, 이 번호와 같은 번호를 할당한 접속 대기 상태의 소켓이 있는지 확인.
  2. 접속 대기 소켓을 복사하여 새 소켓 붙여넣기, 필요 정보 기록
    1. 버퍼 메모리 영역도 같이 확보
  3. TCP헤더 만들기
    1. 송신처의 IP 주소나 포트 번호 등을 기록
  4. IP 가 클라이언트에게 반송
  5. 클라이언트가 패킷을 받았음을 나타내는 ACK 번호가 돌아옴.

→ 서버측의 앱은 accept 를 호출하여 쉬는 상태, 여기에 새로 만든 소켓의 디스크립터를 전달하여 동작 재개

TCP 가 데이터 패킷 수신

  1. TCP 가 패킷이 어느 소켓에 해당하는지 조사
  2. 해당 소켓을 발견하면 데이터 송수신이 올바르게 진행되고 있는지 점검
    1. 데이터 송수신 진행상황과 TCP 헤더 정보 결합
  3. 패킷에 데이터 조각을 추출하여 수신 버퍼에 저장
    1. 데이터를 분할하기 전 상태로 되돌림
  4. 수신 확인 응답용 TCP 헤더에 ACK 번호 기록
  5. IP 가 클라이언트에게 반송

TCP 연결 끊기

TCP 프로토콜 규칙에서는 클라이언트, 서버 어떤 쪽이 연결을 먼저 끊어도 상관 없지만 HTTP 1.0 이라면 서버가 먼저 연결 끊기 동작을 시작한다.

  1. TCP 가 FIN 이라는 컨트롤 비트를 1로 설정한 TCP 헤더 만듬
  2. IP 가 클라이언트에게 보냄
  3. 클라이언트가 ACK 번호 반송
  4. 클라이언트가 close 계속 호출하며 FIN 을 1로 한 TCP 헤더를 서버에 보냄
  5. 서버가 ACK 번호 반송
  6. 잠시 기다렸다가 소켓 말소

서버 응답

웹 서버는 read 에서 받은 데이터 내용이 HTTP Request Message 가 되고, 받은 리퀘스트 메시지에 기록되어 있는 내용에 따라 적절한 처리를 실행해 응답 메시지를 만든다. write 를 통해 이것을 클라이언트에 반송한다.

  • GET 메소드는 단순히 URI 에 기록되어 있는 파일을 디스크에서 읽는 것은 아니다!
    1. 파일을 읽어올 땐 가상의 디렉토리와 실제 디렉토리의 대응 관계 조사 후
    2. 실제 디렉토리 경로명으로 변환 후
    3. 파일을 읽어 데이터를 반송

프로그램 파일의 이름을 URI 에 쓸 수도 있다. 그러면 프로그램이 출력하는 데이터를 클라이언트에 반송한다. CGI 라는 타입의 프로그램도 있다.

리퀘스트 메시지를 보낸 웹 서버는 다음과 같이 동작한다!

  1. 웹 서버가 먼저 URI 부분에 쓰여있는 파일명을 조사하여 이게 프로그램인지 판단한다. 특정 파일 확장자가 일치하면 프로그램으로 간주하거나, 프로그램 디렉토리명을 설정해두기도 한다.
  2. 프로그램을 동작시키도록 OS 에 의뢰한다.
  3. 리퀘스트 메시지에서 데이터를 추출해 작동시킨 프로그램에 건네준다.
  4. 프로그램이 받은 데이터를 처리하여 출력 데이터를 웹 서버에 되돌려준다.
  5. 웹 서버는 이걸 그대로 응답 메시지로 클라이언트에게 반송한다.

액세스 제어

동작을 실행할 때 사전에 설정해 둔 조건에 해당하는지 조사하고, 조건에 따라 액세스 동작 여부를 설정하는 기능.

조건

  1. 클라이언트 주소
  2. 클라이언트 도메인명
  3. 사용자명과 패스워드

클라이언트 주소

  • accept 로 접속했을 때 클라이언트 IP 주소를 점검한다.

클라이언트 도메인명

  • DNS 서버에서 송신처 IP 주소에서 도메인명 판명
  • 도메인명에서 IP 주소 조사 후, 송신처 IP 주소와 동일한지 확인
  • 도메인명을 위조하여 DNS 서버에 등록하는 공격을 방지하기 위해 이중 점검

→ 단점 : DNS 서버의 조회 메시지가 왕래하는 만큼 웹 서버의 응답 시간이 길어진다.

사용자명과 패스워드

  • 사용자명과 패스워드를 확인해 사전에 설정한 것과 대조하여 액세스 여부를 판단한다.

서버 응답

최초에 클라이언트가 리퀘스트 메시지를 웹 서버에 보내는 동작과 같다.

  1. 웹 서버가 write 호출하여 응답 메시지를 프로토콜 스택에 건네줌.
    1. 어느 소켓을 사용하고 있는지 디스크립터를 통지하여 상대 지정.
  2. 프로토콜 스택이 데이터를 분할하여 헤더를 붙여 패킷 송출
  3. 패킷이 스위치나 라우터를 경유하여 클라이언트에게 도착

웹 브라우저의 응답 메시지 표시

데이터 종류 조사

먼저 데이터의 종류를 조사한다.

  • HTTP 헤더에 “Content-Type” 조사
    • Content-Type: text/html; charset = utf-8
      • text : 대분류
      • html : 서브타입 (실제 타입)
      • 종류가 text 인 경우 charset 으로 문자 코드의 정보를 부가한 것을 파악한다.
  • 파일의 확장자명 조사
  • 데이터 내용 조사
    • <html> → HTML 문서구나!

압축 기술이나 부호화 기술을 사용해 데이터를 변환하고 메시지에 저장했다면 어떤 변환을 했는지 조사한다.

  • Content-Encoding

데이터 표시

브라우저가 자체에서 화면 표시 동작을 실행. → 실제 화면 표시 동작은 OS 가 실행한다.

  • 태그가 있다면 브라우저가 화상 데이터 파일을 서버에서 읽어온다.
  • JPEG 나 GIF 형식의 화상 데이터는 압축을 풀고, 데이터를 OS 에 건네주어 표시하도록 한다.
  • 워드프로세서나 프레젠테이션 소프트웨어라는 애플리케이션 데이터라면?
    • 해당 애플리케이션을 호출한다.
728x90