성공과 실패를 결정하는 1%의 네트워크 원리 1장
HTTP프로토콜을 HTML문서나 영상데이터를 별도의 것으로 취급하므로 영상데이터가 많을 수록 소켓을 생성하고, 연결, 데이터를 송수신 하는 동작이 여러번 일어난다.
IP주소 본체 / 넷마스크 (ex. 10.11.12.12/255.255.255.0)
서브넷 마스크 값은 단지 현재 내가 속한 네트워크가 어디까지 네트워크 주소를 표현하는지 명시하는 값일 뿐이다.
호스트 번호 부분의 비트가 모두 0인 것은 각 컴퓨터가 아니라 서브넷(각 클래스로 나눠진 네트워크를 운영중인 서비스의 규모에 맞게 분할하여 사용하기 위한 기술이다) 자체를
나타낸다.(ex 10.11.12.0/24)
호스트 번호 부분의 비트가 모두 1인것은 서브넷 전체에 대한 브로드캐스트를 나타낸다.(ex 10.11.12.255/24)
DNS서버
-
DNS서버는 한번 조사한 이름을 캐시에 기록할 수 있는데 이를 통해 빠르게 회답할 수 있다.
-
캐시에 정보를 저장한 후 등록 정보가 변경되는 경우도 있으므로 캐시 안에 저장된 정보는 올바르다고 단언할 수 없다. 따라서 DNS서버에 등록되는 정보에는 유효기간을 설정하고, 캐시에 저장된 데이터의 유효기간이 지나면 캐시에서 삭제를 한다.
데이터 송수신 동작 단계
1) 소켓 생성하기
디스크립터 : 소켓이 생기면 디스크립터라는 것이 돌아온다. 한대의 컴퓨터에서 복수의 소켓이 존재할 가능성이 있기 때문에 소켓을 식별하기 위해서 사용된다.
소켓을 만든 후 디스크립터를 사용하여 접속 동작이나 데이터 송수신 동작을 실행하는데, 이때 디스크립터를 보여주며 프로토콜 스택이 어느 소켓을 사용하여 접속할지 또는 데이터를 송수신할지를 금방 판단할 수 있다.
2) 파이프를 연결하는 접속 단계
만든 소켓을 서버측의 소켓에 접속하고록 프로토콜 스택(?)에 의뢰한다. 애플리케이션(브라우저?)이 connect(디스크립터, 서버의 IP주소, 포트번호)를 호출한다.
디스크립터 : 프로토콜 스택이 통지받은 디스크립터를 보고 어느 소켓을 서버측의 소켓에 접속할지 판단하여 접속 동작을 실행한다. (클라이언트의 디스크립터)
IP주소 : DNS서버에 조회하여 조사한 엑세스 대상 서버의 IP주소이다.
IP주소로 지정할 수 있는것은 네트워크의 어느 컴퓨터인가 하는 것까지이다. 따라서 IP주소로는 소켓까지 지정할 수 없다. 전화를 걸었을때 "ㅇㅇ님 계십니까?"라고 말하여 통화할 상대를 바꿔달라는 중간 과정이 필요한데, 이 중간 과정이 포트번호입낟. IP주소와 포트 번호의 두가지를 지정해야 어느 컴퓨터의 어느 소켓과 접속할지를 분명히 지정할 수 있다.
그렇다면 포트번호가 아닌 서버측의 디스크립터로 연결하면 안될까?
디스크립터는 소켓을 만들도록 의뢰한 애플리케이션에 건네주는 것이지, 접속 상대에 건네주는 것이 아니므로 접속 상대측에서는 그 값을 모른다.
디스크립터는 컴퓨터 한 대의 내부에서 소켓을 식별하기 위해 사용하지만, 포트 번호는 접속 상대측에서 소켓을 식별하기 위해 사용합니다.
서버측의 포트 번호는 애플리케이션의 종류에 따라 미리 결정된 값을 사용한다는 규칙이 있다. 즉, 웹은 80번, 메일은 25번이라는 식입니다.
포트번호가 접속 상대측에서 소켓을 지정하기 위해 사용하는 것이라면 서버에서도 클라이언트측의 소켓의 번호가 필요할 텐데 이 부분은 어떻게 될까?
- 먼저 클라이언트측의 소켓의 포트 번호는 소켓을 만들 때 프로토콜 스택이 적당한 값을 골라서 할당한다. 그리고 이 값을 프로토콜 스택이 접속 동작을 실행할 때 서버측에 통지합니다.
정리하자면 connect를 호출하면 프로토콜 스택이 접속 동작을 실행한다. 그리고 상대와 연결되면 프로토콜 스택은 연결된 상대의 IP주소나 포트 번호 등의 정보를 소켓이 기록한다. 이로써 데이터 송수신이 가능한 상태가 된다. (89p)
3) 메시지를 주고받는 송수신 단계
- 애플리케이션은 송신 데이터(URL을 바탕으로 만든 HTTP리퀘스트 메시지)를 메모리에 준비한다.
그리고 write를 호출할 때 디스크립터와 송신 데이터를 지정한다. 그러면 프로토콜 스택이 송신 데이터를 서버에게 송신한다.
그러면 서버는 수신 동작을 실행하여 받은 데이터의 내용을 조사하고 적절한 처리를 실행하여 응답 메시지를 반송한다.
수신할 때는 Socket라이브러리의 read라는 프로그램 부품을 통해 프로토콜 스택에 수신동작을 의뢰한다. 이때 수신한 응답 메시지를 저장하기 위한 메모리 영역을 지정하는데, 이 메모리 영역을 수신 버퍼라고 부른다. 수신 버퍼는 애플리케이션 프로그램의 내부에 마련된 메모리 영역이므로 수신 버퍼에 메시지를 저장한 시점에서 메시지를 애플리케이션에 건네준다.
4) 연결 끊기 단계에서 송수신이 종료됩니다.
웹에서 사용하는 HTTP 프로토콜에서는 본래 응답 메시지의 송신을 완료했을때 웹 서버측에서 연결 끊기 동작을 실행하므로 먼저 웹 서버측에서 close를 호출하여 연결을 끊는다. 이것이 클라이언트측에 전달되어 클라이언트의 소켓은 연결 끊기 단계로 들어갑니다.
buffer는 임시저장장소와 같은 것으로 파일에 어떤것을 작성하라는 명령이 내려진다면 LINUX는 즉시 파일에 데이터를 쓰지 않고 버펴에 담아두다가 CPU가 바쁘지 않을 때 쓰게 된다.
cached는 버퍼와는 다른의미로 메모리에서 사용되었던 실행이미지를 잠시동안 보관하고 있는곳이다. cached를 사용하는 이유는 자주 사용하는 프로그램을 빠르게 실행하기 위해서이고, 이렇게 함으로써 실행도 빨라지지만 HDD에 접근하는 횟수도 휠씬 줄어들 수가 있다. 즉 쉽게 말해 캐시는 더 빠른 접근을 위해 자주 사용하는 데이터를 저장하기 위한 공간이라고 생각하면 된다.
프로토콜 스택이란 데이터 통신에 활용되는 프로토콜의 구조에 관한 개념으로 계층화된 구조로 모여 있는 프로토콜의 집합을 말한다.
버퍼와 캐시의 의미
서브넷 마스크
