🤔인터넷은 어떻게 통신할까?
인터넷은 packet-switching, datagram 방식으로 application-layer(5계층)의 메세지들을 packet으로 쪼개서 전송한다.
+) packet: 통신 단위
🧐그럼 packet은 어디로 어떻게 갈까?
각 end-host(클라이언트, 서버)는 IP주소를 부여받는데 패킷에 정보가 들어있다. 하지만 IP(Internet Protocol)는 다음과 같은 특성을 가지고 있다.
1. 비연결성(Connectionless): 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
2. 비신뢰성(Unreliable): (flow, error, congestion)control 등등 안해줌.
-> 중간에 패킷이 사라지는 문제와 보낸 순서대로 받지 못해도 모름😓문제가 너무 많은거 아닌가?
-> IP(3계층)위의 TCP/UDP(4계층)에서 이를 해결한다.
UDP는 좀 다르지만 대부분 TCP를 사용하기에 TCP를 정리하겠다.
1. 연결성(Connection-oriented): logical connection을 생성
2. 신뢰성(Reliable): (flow, error, congestion)control 지원
-> 데이터 전달 보증(누락, 순서 확인)
이런 식으로 IP계층으로 내려가기 전에 TCP에서 한 번 더 감싸서(encapsulation) 보내는 것이다.
TCP헤더에는 출발, 목적지 PORT와 신뢰성을 지키기 위한 정보들이 들어가 있는 것이다.
💭한 번에 두 가지 이상의 app에서 전송 받으려면 어떡해?
IP 주소는 한가지인데 어떤 app에서 온 것인지 구분을 어떻게 할까?
이는 PORT를 사용해서 구분을 하는데 IP내에서 여러 포트가 있고, 각 PORT를 할당받아서 같은 IP내에서 프로세스를 구분하는 것이다.
IP(하나의 서버, PC): 아파트
PORT: 몇 동, 몇 호TCP헤더에 PORT번호가 있기에 이처럼 여러 앱을 실행하는 것이 가능한 것이다.
PORT 번호는 0 ~ 65535 할당이 가능한데 0 ~ 1023번 포트는 잘 알려진 포트로 사용하지 않는 것이 좋다. ex) HTTP는 80번, HTTPS는 443번 포트 사용.
👻근데 IP는 불변하지 않다.
IP는 100.100.100.1 이런식으로 복잡하기도 한데 바뀌기까지 한다. (고정 ip를 신청한 것이 아니면 공유기를 껐다 켰다하면 바뀔 수 있다)
헐.. 그럼 어떡해? -> DNS
우리는 IP를 통해 통신하는데 바뀌면 어떡할까?
이와 같은 문제를 해결하기 위해 DNS(Domain Name System)을 사용하는데 전화번호부라고 생각하면 된다.
즉 DNS서버에서 도메인 명과 IP를 관리하는데 IP가 바뀌어도 DNS서버에 등록만 한다면 IP가 바뀐 사실을 몰라도 클라이언트들은 도메인명에 접근하면 되는 것이다.
| 도메인 명 | IP |
|---|---|
| google.com | 100.100.100.1 |
| naver.com | 200.200.200.2 |
📡 HTTP
위에서는 end-host와 end-host 간의 통신이 이루어지는 이유에 대해 살펴봤다.
그렇다면 통신 내에서 메세지가 전달되는 방식에 대해 알아보자.
인터넷은 client - server 구조로 작동된다.
이때, HTTP(HyperText Transfer Protocol)를 사용하는데,
그냥 통신때 HTTP 메세지에 모든 것을 전송한다고 보면 된다.
HTML, TEXT, IMAGE, VOICE, VEDIO, FILE,
JSON, XML . . . .(HTTP로 요청하고, 응답받고 그런식... )
HTTP의 특성은 다음과 같다.
- 무상태(stateless): 서버가 클라이언트의 상태를 보존하지 않는다.
-> 서버 확장성이 높지만 클라이언트가 추가 데이터를 전송해야한다.
- 비연결성(connectionless)
-> 서버 자원을 매우 효율적으로 사용하지만 TCP/IP 연결을 매번 보내야 하는 단점이 있다.
=> HTTP 지속연결(Persistent Connections)로 문제 해결: 바로 연결을 끊지 않고
일정 시간 뒤에 연결을 끊는다.그럼 HTTP는 어떻게 생겼을까?
HTTP를 뜯어보자 ‼️
HTTP 메시지 구조는 그림의 오른쪽과 같이 구성돼있는데, Request부분에서는 message body가 필수적이지 않다는 것과 각 부분의 구성요소가 뭔가 다르다는 것을 알 수 있다.
그렇다면 각 부분이 어떻게 작성돼야 하는지 살펴보자.
시작 라인
요청 메세지: method 공백 request-target 공백 HTTP-version 엔터
(method: GET, POST, PUT, DELETE . . .)
(request-target: absolute-path[?query] (절대경로[?쿼리])
(HTTP-version: HTTP/1.1을 가장 많이사용, /2, /3도 있음)응답 메세지: HTTP-version 공백 status-code 공백 reason-phrase 엔터
(status-code: 요청 성공, 실패 등등을 나타내는 상태코드
200: 성공, 400: 클라이언트 요청 오류, 500: 서버 내부 오류..)
(reason-phrase: 사람이 이해할 수 있는 짧은 상태 코드 설명 글)
HTTP 헤더
header-field = field-name ":" OWS field-value OWS
(OWS= 띄어쓰기 허용, field-name은 대소문자 구분 안함)
ex) Host: www.google.com
Content-Type: text/html;charset=UTF-8HTTP 전송에 필요한 모든 부가정보 (메시지 바디 내용, 크기, 클라이언트 정보, 서버 정보, 캐시 정보 등등......)가 들어있다.
HTTP 메시지 바디
실제 전송할 데이터로 HTML, IMAGE, VIDEO, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능하다.
이 글은 inflearn 김영한 님의 강의를 기반으로 하여 데이터통신, 컴퓨터통신의 내용을 추가하여 작성하였습니다.
https://www.inflearn.com/course/http-웹-네트워크
틀린 개념이나 궁금하신 점이 있다면 편하게 댓글 달아주시면 감사하겠습니다 :)
