서버
서버는 복수의 클라이언트와 상호작용함. 하나의 프로그램으로 상대하긴 어려움
멀티 스레드와 멀티 프로세스기능을 사용해 다수의 클라이언트를 상대.
소켓 접속에 성공하면 프로세스/스레드를 생성해서 대응.
TCP의 방식은 사실 좌우 대칭. 서버, 클라이언트를 나눌 필요가 없음.
다만 소켓 접속,대기만 대칭이 아님.(서버가 먼저 대기)
서버측 소켓의 개요는 대략적으로 이렇다.
socket()으로 소켓 작성bind()로 포트번호 기록
2-1.listen()으로 소켓 접속 기다리는 상태라고 제어정보 기록. 여기까지가 소켓 접속 대기.
이 상태의 소켓 복사해서 다수 클라이언트 상대accept()로 클라이언트의 접속 허용
2번에서 소켓을 복제할때 포트도 똑같이 복제. 이러면 소켓 구분불가능.
=> 클라이언트측 제어정보도 기록한다.(클라이언트측 IP와 포트, 서버측 IP와 포트)
디스크립터는 특정 정수값인데, 클라이언트 측정보를 받기전까지 구분하기위해 사용.
서버의 수신동작
클라이언트측 수신동작과 일치. 복습겸 다시 설명해봄.
- 흘러온 패킷 신호를 LAN어댑터에서 디지털 데이터로 바꿈.
1-1. 프리앰블에서 클록신호 추출 후 연장
1-2. 스타트 프레임 딜리미터이후부터 데이터 추출 - FCS와 오류검산식 일치하는지 확인
- MAC헤더의 수신처 자신과 일치하는지 확인
- LAN어댑터 버퍼메모리에 저장.
여기까지는 LAN어댑터의 MAC회로 부분이 실행
- 서버의 CPU가 인터럽트됨.
- LAN드라이버가 동작하여 버퍼메모리 패킷 추출.
- 이후는 MAC헤더필드값에 따라 프로토콜 처리 소프트웨어호출.(여기선 IP라 가정. TCP/IP호출)
- IP헤더의 fragmentation(패킷 조각나누기)판별. 나눠져있으면 메모리에 일시저장후 다 오면 프로토콜로(여기선 TCP) 넘겨줌.
- TCP헤더 SYN값 1이면 접속동작 패킷. 따라서 수신처 포트와 일치하는 소켓 찾음.
없으면 ICMP로 오류 통지. 있으면 소켓복제 후 제어정보 기입. 송-수신메모리영역 확보. - ACK, 시퀀스 초기값, 윈도우 사이즈 등 TCP헤더에 실어서 응답.(헤더만있음 데이터 x)
- socket에게 제어권 넘겨준 서버측 애플리케이션이 디스크립터전달받고 동작 재개.
아래부턴 데이터패킷 도착 후
- 송신처 IP,포트번호와 수신처 IP,포트번호일치하는 소켓 찾음.
- 시퀀스 번호 계산해가며 데이터 조각 연결. 완료되면 수신버퍼저장
- 클라이언트에게 ACK 응답.
- 애플리케이션은
read()로 수신버퍼의 데이터 꺼내옴. close()로 소켓 말소
웹서버 소프트웨어가 리퀘스트 해석-응답
웹서버의 동작은 거진 공통. 요청을 받아서 처리하는 방법만 다를 뿐(HTTP 메소드).
또한 클라이언트가 요청한 URI !== 실제디렉토리. 같으면 웹서버 디스크 노출.
node로 백엔드 제작할때 api 경로설정했던걸 떠올려보자.
액세스 제어
방화벽의 패킷 필터링기능처럼 특정 조건에 부합하는 클라이언트만 액세스가능하게 할수있음.
예를들면 로그인. 사내의 특정 부서(도메인 or IP).
도메인을 알아내려면 클라이언트의 IP로 조회를 해야함. 요청 => 서버 => 서버측 DNS => 클라이언트측 DNS가 응답.
로그인같이 인증정보가 필요한 경우 서버측에서 헤더에 WWW-Authenticate를 실어보냄(요구). => 클라이언트는 Authorization에 인증정보 기입.
웹서버의 응답 메시지 받아 출력
우리 여정의 마지막 단계다!
웹서버의 응답메시지는 조각조각 나뉘어 클라이언트에게 들어옴.
랜 어댑터에서 전기 신호 => 디지털 신호 => 데이터로 변환, 프로토콜 스택이 조각난 패킷 합침 => 브라우저도착.
Content-Type: x/y(콘텐츠 헤더)
브라우저가 데이터의 종류를 판단하는 근거중 하나.
설정하지 않는다면 ? => 파일 확장자로 판단하거나, html태그를 보거나 해서 판단함.
최근의 통신은 JSON위주로 하기에 express같은 프레임웤들의 기본값이 Content-Type:application/json으로 되어있음.
