개발공부 기록지

웹의 짝궁 HTTP

커피숍에서 주문없이 자리에만 앉아 있으면 커피는 제공되지 않는다.

→ 요청(주문)이 없으면 응답(커피)이 없다.

Http(hypertext Transfer Protocol)??

웹 브라우저와 웹 서버간에 데이터를 주고 받기 위해 사용하는 프로코콜

하이퍼텍스트 형태의 데이터뿐만 아니라 이미지나 동영상 형식도 전달가능

특징

• 클라이언트/서버 모델을 따른다
  • 서로 관계를 맺고 있는 컴퓨터가 클라이언트와 서버라는 두 역할로 구분된다.
  • 클라이언트와 서버는 서로 HTTP 메세지를 주고 받으며 통신을 하는데 이걸 요청/응답 메세지라고 한다
    • 클라인언트 → 서버 (요청 : 커피 주문)
    • 서버→ 클라이언트 (응답: 커피)
• 상태를 가지지 않는다(stateless), 비연결성 프로토콜
  • 과거의 대화내용을 기억하지 않는다.
  • 첫번째 통신에서 데이터를 주고 받아도 두번째 통신에서는 첫번째 통신에서 주고 받은 데이터를 유지하지 않는다.

장점 : 데이터를 유지하는 비용이 없다

단점 : 요청 할 때마다 3방향 핸드쉐이크를 해야한다.

HTTP의 구조

요청 메세지의 구성요소 설명

헤더

HTTP 메세지에 대한 추가 정볼르 제공하기 위해 사용

빈줄

헤더와 본문을 구별하기 위함

본문

요청 메세지에서는 채워져 있는 경우가 드뭄

사용되는 경우?  회원가입에 필요한 정보를 담기 위한 경우와 같은 경우에 채워져 있다. 

응답 메세지의 구성요소 설명

상태코드

클라이언트 요청에 따른 서버의 응답상태를 숫자로 나타낸것

참고:  https://joey0203.tistory.com/28

본문

요청에 관한 자원이 표시되는 곳

자원이 유형에 맞는 형식으로 표시 ( HTML 코드, 이미지, 동영상, ... )

GET vs. POST,  PUT vs. PATCH

요청 메서드의 종류

HEAD :  HTTP 헤더 정보만 요청. 웹 서버가 정상적으로 작동하는지 등 서버 상태를 미리 확인 하기 위해 사용

PUT / PATCH

• PUT : 특정 데이터 전체를 교체할 때(수정할 때)
• PATCH : 특정 데이터의 일부를 교체할 때 (수정할 때)

      참고 그림

OPTION : 서버 측에서 제공 할 수 있는 메서드가 무서인지 알기 위해 사용

 ex) 클라이언트에서 option 메서드를 달아 요청을 보내면  서버에서 다음과 같이 응답  "Allow : GET, POST, HEAD"

안전한 메서드, 멱등성을 가진 메서드

안정성 : 클라이언트가 요청을 해도 서버의 자원(데이터)이 변하지 않는 특성을 의미

• 안정성 O  = GET, HEAD, OPTIONS 
• 안정성 X  =  POST, PUT, PATCH, DELETE

멱등성 (idempotent) : 연산을 여러 번 적용을 해도 결과가 달라지지 않는 특성

• 멱등성  O = GET, HEAD, PUT, DELETE, OPIONS
• 멱등성  X = POST, PATCH

헤더가 왜 중요할까?

TCP/IP 와 HTTP의 공통점은 바로 헤더가 있다는 점.

헤더는 데이터에 대한 추가 정보를 제공하며, 헤더가 커지면 덩달아 전체 데이터의 크기도 커지기 때문에 필요한 정보만 담는 것이 중요하다.

그러므로 헤더에는 해당 데이터에 대한 핵심 정보를 바로 파악할 수 있는 정보가 들어 있다.

HTTP 헤더의 특징

• 사람이 읽을 수 있는 형태로 작성
• 자유로운 형식
• 클라이언트와 서버가 필요한 만큼 헤더를 작성 가능
  • 각 정보의 위치가 정해져 있는 것 이 아니라 원하는 위치에 알아서 필요한 만큼 정보 입력 가능
  • 급식판이 아닌 뷔페에 가면 있는 큰 접시와 같은 느낌.

크롬 브라우저에서 직접 헤더 확인하기

F12 를 누른 후 -> Network 탭 선택 -> 보이는 데이터를 선택하 -> header 탭을 선택하면 확인 가능 

HTTP 헤더의 종류

<그림>

공통 헤더 (General header)

• 요청 메세지와 응답메세지가 모두 적용되는 헤더
• 대표적인 헤더 예시
  • Date - 메세지가 발생한 날짜와 시각을 표현
  • Cache-Control - 기존에 받은 데이터를 저장할지 여부를 정함

요청 헤더 (Request header)

• 요청 메세지를 작성
• 클라이언트에 대한 정보 또는 변경될 데이터에 관한 내용을 포함
• 대표적인 헤더 예시
  • Host - 데이터를 요청하는 서버의 호스트 이름
  • User-Agent - 클라이언트의 정보

응답 헤더 (Response header)

• 응답 메세지에 대한 정보를 담고 있는 헤더
• 대표적인 헤더 예시
  • 웹 서버의 종류(server) 등 서버에 대한 정보가 있음

엔티티 헤더 E(Entity header)

• 메세지 본문에  대한 정보를 포함하는 헤더
• 대표적인 헤어 예시
  • 본문의 길이 ( Content-length)
  • 자원의 미디어 타입(Content-type)
  • 본문의 언어(content-language)

(추가)

accept - 접두어 : 이 헤더는 이런 응답만 허용하겠다는 의미

상태 코드로 통신 상태 한눈에 파악하기 

상태코드란?

클라이언트의 요청에 따른 서버의 응답 상태를 세 자리 숫자로 나타낸것

예) Status Code : 200 

5 가지 클래스로 알아보는 상태코드

<사진>

1XX Class  조건부 응답, 웹 서버가 현재 요청을 받았으며 작업을 진해하고 있다는 의미

2XX Calss  클라이언트가 요청한 작업을 서버가 성공적으로 처리 했음을 의미

3XX Calss  리다이렉션 완료 응답, 요청을 완료하기 위해 재전송이 필요하는 의미

4XX Class 클라이언트 측에 오류가 있음을 의미

5XX Class 서버가 요청을 수행하지 못했을 을 의미

자주 쓰이는 상태코드 설명 여기 참고 : https://joey0203.tistory.com/28

보안을 책임지는 요소들 : SSL, TLS, HTTPS

HTTP의 한계, 보안

HTTP의 문제점

1. 누구나 볼 수 있게 암호화하지 않은 상태로 전송

2. 통신 상대를 확인 하지 않는다

이로 인한 대표적인 보안문제 -> 중간자 공격 (Man in the middle attack, MITM)

네트워크 통신 도중 중간자가 침입해 통신 내용을 도청하거나 조작하는 공격 기법.

ex) 중간에서 공인인증서 위조, 회원가입시 비밀번호 유출

해결책 -> HTTPS (Hypertext Transfer Protocol Secure)

보안을 책임지는 HTTPS

누구나 볼 수 있었던 메세지를 통신하는 당사자만 볼 수 있게 암호화

URL 이 https:// 로 시작하고 앞에 자물쇠 아이콘이 달린모습으로 우리에게 보인다.

SSL과 TLS는 무엇이 다를까?

HTTPS의 암호화를 담당하는 곳

-> SSL (Secure Socket Layer), 클라이언트와 서버가 서로 데이터를 암호화해 통신할 수 있게 돕는 보안 계층

TLS (Transport Layer Security) ? 

SSL 과 같은 보안 프로토콜, SSL 3.0 버전 다음 부터 등장한 이름

대다수의 보안 프로토콜이 TLS 사용

대칭키, 공개키로 안전하게 암호화하기

대칭키 

하나의 키로 암호화와 복호화를 둘 다 할 수 있는 암호화

장점 : 공개키 방식에 비해 속도가 빠르다

단점 : 서로 키를 안전하게 교환하기가 어렵다, 중간에서 누군가 키를 가로챌 위험 존재 

공개키 

대칭키 단점을 보완하기 위해 탄생

서로 다른 키 두 개로 암호화와 복호화를 한다.

사용하는 두개의 키는 공개키, 개인키, 이 두 키는 늘 한 쌍으로 동작

>  암호화 / 복호화 방법

상자를 빨간 (파란) 열쇠로 잠구면,
남아있는 파란 (빨간) 열쇠로만 상자를 열기 가능 

> 장점 : 대칭키보다 더 안전하게 데이터를 주고 받을 수 있다.

> 단점 : 암호화 과정이 복잡하여 속도가 느리다.

SSL 동작 과정 : 핸드셰이크, 세션, 세션종료

1 단계 : 서버에게 인사 = 서버에 데이터 전송
             → < 랜덤데이터 : "Hi",  현재 지원가능한 암호화 방식을 서버에 전달>

2 단계 : 클라이언트에 데이터 전송
             → < 랜덤데이터 : "Hello", 지원가능한 암호화 방식, 발급 받은 서버 인증서 >
                   *인증서 = CA(Certificate Authority) 에서 발급받은 문서 : 서버가 신뢰할 수 있는지 보장하는 문서  

3 단계 : 인증서 검증, 인증서 복호화

             → CA에서 공유하는 공개키로 인증서 복호화

4 단계 : 대칭키 생성 및 암호화하여 서버에 전달

             → 임시 대칭키 생성 ( 주고 받은 랜덤데이터를 이용 : "Hi" + "Hello"),  공개키로 암호화하여 서버에 전달

5 단계 : 비밀키로 복호화( 암호 해독 ) 

             → 서버가 가지고 있던 비밀키로 암호를 해독하여 클라이언트와 같은 임시 대칭키를 보유

6 단계 : 세션키 생성
             → 클라이언트와 서버가 가지고 있는 키를 일련의 과정을 거쳐서 세션키로 변경

SSL 은 두 개의 암호화 방식 (대칭키 기법, 공개키 기법)을 사용해 신뢰할 수 있는 데이터 통신환경을 제공

간략히 보는 HTTP 변천사

초기 HTTP 

GET 메소드만 지원

HTTP의 시작, HTTP/1.0

GET + HEAD, POST 지원

클라이언트와 서버간의 원활한 통신 가능

요청 마다 새로운 연결을 맺아야 한다.

표준,  HTTP/1.1

• 지속적 연결 상태 ( Persist Connection) :  요청마다 TCP 연결을 해야하는 문제(1.0 버전)를 해결, 메모리 자원 절약
• 파이프라이닝 ( Pipelining) : 응답이 도착해야만 다음 요청을 보낼수 있는 문제(1.0 버전)을 해결, 통신 지연문제 해결

더 빠르게,  HTTP/2

SPDY 프로토콜을 도입하여  성능 및 속도 개선

성능 및 속도를 개선한 방법

1. 스트림 다중화 (Multiplexed Streams)  한 연결 안에서 여러 개 의 메세지를 주고 받을 수 있게 됨

2. 서버 푸쉬(server push)  이용하여 클라인언트가 굳이 요청하지 않아도 서버에 미리 필요한 리소스를 푸쉬 가능

3. 바이너리 프레이밍 (binary framing)  HTTP 메세지를 더 작은 단위로 쪼개 010101 같은 바이너리 형태로 캡슐화 

       이로 인해서 스트림 다중화와 서버 푸쉬가 가능해졌다.

따끈한 새 버전, HTTP/3

HTTP/2 에서 해결하지 못한 문제를 해결

* TCP 는 데이터를 무조건 순서대로 처리

(문제) HOLB(head of line blocking) :

중간에 일부 데이터가 손실되면 이를 해결하는 동안 다른 데이터 처리 불가능

병목현상 발생

해결책

QUIC ( Quick UDP Internt Connection) : TCP 가 아닌 UDP 기반에서 작동하는 프로토콜

• 빠른 속도 보장
  • TCP 의 3 방향 핸드쉐이크 생략
  • TLS 에서 암호화과정 생략
• 데이터 검증을 통한 신뢰성 보장

• 멀티플렉싱(Multiplexing) 기법 : 데이터를 독립적으로 다룸 -> TCP 에서의 병목현상 해결

• TLS 대체 : TLS 에서 데이터 암호화과정 생략 됨

4장에서 IP 는 데이터 전달을 제외한 나머지는 신경을 안쓴다고 하여 데이터가 완전히 받을 수 있을지 의문이 드는데

TCP 가 언제 어디서든 데이터를 온전히 가져다 주기위한 프로토콜이다.

TCP :전송 제어 프로토콜

• 신뢰성있는( 언제 어디서든 데이터를 온전히 가져다 줄거라는 믿음) 있는 통신을 위한 프로토콜
• 데이터 유실의 오류를 감지하고 해결해 데이터가 온전히 전송 될 수 있게 해준다.

패킷 유실의 문제를 해결하는 방법?

• TCP가 패킷마다 번호를 붙여서 무엇이 사라졌는지 확인을 한다.
• TCP 에서 데이터를 주고 받을 때 확인 절차를 추가
  • 서버가 클라이언트에게 데이터를 잘 받았다는 메세지를 받았는 지 확인하고 받지 못했다면 다시 데이터를 보내어 확실하게 클라이언트가 데이터를 받을 수 있게 보장.

※ 패킷, 클라이언트?

패킷

데이터를 전송할때 사용되는 작은 컨테이너 개념,

네트워크 통신을 할 때 사용되는 작게 분할된 데이터 조각으로 네트워크에서 전송하는 데이터의 기본 단위

클라이언트

서버에서 보내는 서비스 요청

지금 데이터 상태는? 헤더와 플래그

해당 데이터에 대한 정보가 담겨 있는 헤더 (header)

패킷의 상태를 알리는 목적의 헤더 정보인 정보 플래그(flag) -> 다른 기기에 신호를 전달하기 위한 용도

TCP 헤더의 플래그 종류

• ACK (Acknowledgement) : 앞서 받은 데이터를 잘 처리 했다는 의미
• SYN (Synchronize) : 연결을 요청하는 플래그
• FIN (Finish) : 통신이 마무리되어 연결의 해제를 요청하는 플래그

TCP 헤더 전체 그림

TCP에서 연결을 수립하고 해지하는 과정

시작은 3방향 핸드쉐이크

 3번의 메세지 교환을 통해서 클라이언트와 서버간의 연결을 수립하기 위해 준비하는 방식

아래의 그림과 같이 클라이언트와 서버가 서로 데이터를 주고 받을 수 있는 상태인지 확인을 하는 방식

마무리는 4방향 핸드쉐이크

4번의 메세지 교환을 통해서 클라이언트와 서버간의 연결을 끝내는 방식

연결종료 신호 (FIN) 을 받고 time_wait를 하는 이유는 클라이언트 쪽에서 혹시 모를 일 (예를 들어 아직 도착하지 못한 패킷)에 대비 해 잠시 기다렸다가 최종적으로 서버에 응답(ACK) 를 보내서 종료 시킨다.

사이 좋게 데이터를 주고 받는 방법

흐름제어

데이터를 주고 받을 때 전송자가 빠르거나 수신자가 빠를 수도 있다. 이때 상호간의 속도를 무시하고 전송하면 데이터 손실 같은 오류가 발생 할 수 있다. 그러므로, 전송자와 수신자의 속도에 따라 데이터 전송 속도를 조절 하는 것 을 말한다.

정지-대기방식

데이터의 손실? 을 막기 위해 클라이언트와 서버간에 아래와 같은 확인 절차를 거치는 방식.

서버 →(데이터)→ 클라인언트 →(응답:ACK)→ 서버

장점 : 데이터가 확실하게 전송되었는지 확인 가능하다.  신뢰성이 높다.

단점 : 하나하나 확인을 해야 하므로 시간이 올래 걸린다. 효율성이 떨어진다.

슬라이딩 윈도우 방식

한번에 여러개의 데이터를 보내서 하나하나 확인을 하지 않아도 되게하는 방식으로 아래의 그림과 같이 작동한다.

데이터를 윈도우 크기만큼 전송하고 수신자가 수신한 데이터에 대한 응답을 보내는 데 이때 헤더에 데이터 번호가 적혀있다.

윈도우라고 부르는 이유는 확인된 데이터 번호 다음으로 이동하여 다시 데이터를 전송하는 방식이므로 슬라이드 윈도우 하고 정함.

주로 전송자가 수신자의 윈도우 크키를 파악해서 전송한다.

혼잡 제어로 네트워크 나누어 쓰기

혼잡 제어

혼잡은 '수신자'가 전송자가 데이터를 보냈지만 네트워크 처리속도가 느려서 '재전송'을 요청하고 전송자는 데이터가 유실되었다고 판단하여 데이터를 '재전송'하는 상황에서 발생한다. → 네트워크 내에 패킷의 수가 과도하게 증가

이러한 혼잡을 제어하기 위한 기능

혼잡 제어 원리

천천히 데이터를 전송하다가 수신자가 잘 받으면 속도를 상승시킨다. 수신자의 데이터 수신 상태에 따라 속도를 조절

예를 들어 4번 데이터를 전송할 차례인데 수신자가 2번 데이터까지만 받았을때 속도를 늦춘다.

합 증가/감소

• 수신자가 잘받았는 신호가 올때 마다 윈도우 크기를 1씩 증가
• 신뢰성 높다
• 속도를 증가시키는데 시간이 걸린다.

느린시작

• 2배씩 증가하여 시간이 지날수록 많은 양의 데이터 전달 가능.
• 느린시작인 이유 : 기존의 TCP 방식보다 시작이 느려서이다. 
  • 한번에 수신자가 받을 수 있는 최대 윈도우로 보내기 보다 1 부터 시작

더 빠르게 UDP (User Datagram Protocol)

TCP vs UDP

UDP는

전송자와 수신자가 연결이 되어있는 보장을 하지 않는다. → 비연결형

프레임 1~2개 정도 잠깐 안보여도 상관이 없는 실시간으로 화면을 보여줘야하는 게 중요한 상황에 사용 → 온라인 게임, 스트리밍에 적합

IP

• 인터넷에서 데이터를 주고받을때 사용하는 통신 규약
• 패킷(packet)을 정해진 목적지까지 운반하기 위해 사용
  • 패킷: 하나의 데이터를 잘게 작게 자른 것
• 패킷의 전달을 책임지는 프로토콜이고 패킷의 손시이나 중복과 같은 상태 이상은 확인하지 않는다.
  • 비신뢰성(상자 안 내용물의 상태를 보장 x) 과 비연결성(받는 사람이 있는지를 고려 x) 특징을 가진다.

즉, IP는 인터넷 통신을 담당하는 프로토콜이다. 데이터를 전달(배송)하는 것 을 제외한 나머지는 신경을 쓰지 않는다.

IPv4 주소의 구조

194.168.0.1 → 네트워크(194.168.0), 호스트(1)

192 -> 11000000 (8 비트)  →  IPv4 는 총 32 비트

8비트 = 1 옥텟, 1 옥텟은 0~255 까지 표현가능

네트워크 와 호스트 주소

IPv4 주소에서의

• 네트워크 = 데이터를 통신하는 과정에서 같은 공유기를 사용하는 범위
• 호스트 = 이 네트워크에 연결된 각각의 장치(기기)

즉, 네트워크는 빌라의 주소, 호스트는 호수라는 개념이다.

(주의) 호스트는 0~255 까지 가능하지만 0 과 255는 사용할 수 없다.

• 첫 번째 IP주소 - 194.168.0.0 은 네트워크 그 자체의 주소
• 마자막 IP주소 - 194.168.0.255 는 브로드캐스트 주소

브로드캐스트 주소?

네트워크 주소에 속한 모든 호스트에 패킷을 전달해야 할때 사용하는 주소

즉, 브로드캐스트 주소로 전달된 내용은 같은 네트워크 안에 있는 모든 호스트에게 똑같이 전송된다.

클래스 ?

IP 주소당 호스트 주소의 개수를 고정하게 되면...

• 호스트가 많은 조직의 경우 하나의 IP 주소만으로 충분 X → 여러 IP 주소이용
• 호스트가 작은 가정집 같은 경우는 → 낭비되는 호스트 주소 발생 

이 문제를 해결하고자 클래스라는 개념이 탄생 →  즉. 이제 ( 적게 / 보통 / 많이) 같은 선택지가 생김

클래스구분 및 첫 번째 옥텟의 범위를 아래에 그림으로 추가.

하지만.. 전 세계적으로 IPv4 가 부족한 현상이 발생하여 새로운 개념을 고안 = CIDR

CIDR 와 서브넷 마스크

CIDR ( Classless Inter-Domain Routing, 사이더) 는 클래스 없는 도메인 간 라우팅 기법으로 클래스가 없어도  IP 주소 할당 가능

ex) 밥양에 비교

CIDR ▷▷▷ 클래스 할당방식보다 더 잘게 IP 주소를 사용할 수 있음

• 사용자들은 필요한 호스트 개수 만큼 사용가능
• 부족한 IP 주소도 더 효율적으로 활용 가능

CIDR 에서 네트워크 부분과 호스트 부분을 구분 하는 방법?  ▷ 서브넷 마스크( subnet mask)

서브넷 마스크는 네트워크와 호스트 부분을 구분해주는 역할로 클래스 기반 할당방식일때 도 존재

서브넷 표기방식 =  IPv4주소 와 같게 32비트로 표시한다. 예시로 아래 그림을 참고

위의 그림에서 볼수 있듯이 호스트부분은 0 이있는 자릿수를 호스트 부분으로 구분가능

(중요) 서브넷 마스크의 1은 연속적으로 배치해야한다. 만약 1110011 식이면 어디까지가 네트워크부분인지 알수 없기 때문

CIDR 표기 방식

위의 예시의 경우 IP주소를 그대로 작성하고 뒤에  / 와 24 를 붙인다. 

이유는 서브넷 마스크에서 연속된 1이 총 24개 가 있기 때문

주소고갈 문제 해결

1. 유동(dynalmic) IP 사용

DHCP(Dynamic Hose Configuration Protocool) = 자동으로 IP주소를 자동으로 임대기간동안 할당하고 기간이 끝나면 반환

2. 공인 IP 와 사설 IP

공인 IP : 인터넷상에서 유일한 주소이자 ISP에서 공식으로 할당하는 주소

사설 IP : 상세주소에 해당하며 특정 네트워크 내에서 사적인 용도로 이용하는 주소 ( 공인 IP 속에 있는 가상 IP 주소?)

 --> IP주소를 찾을 때 구글에서 검색했을 때의 주소와  터미널에서 ipconfig, ifconfig로 찾은 주소가 다르다면 하나는 사설IP 이다. 

사설 IP 와 공인 IP를 구별하기위해 정해진 사설 IP 주소 대역

10.0.0.0 ~ 10.255.255.255

172.16.0.0 ~ 172.31.255.255

192.168.0.0 ~ 192.168.255.255

그럼 사설 IP는 아파트 호수 처럼 중복이 될수 있는데 어떻게 외부와  통신을 주고 받을까? NAT(Network Address Translation) 이용

• 사설 IP 주소 → NAT(주소 변환) → 공인IP 주소

즉, 같은 네트워크 안에서는 사설 IP 를 사용하지만  외부와 통신할때는 공인 IP로 변환 해서 사용한다. 

3. IPv6 이용

URL (Uniform Resource Locator) ?

웹상에서 원하는 자원(웹사이트, 문서, 이미지, 동영상등)을 정확히 찾을 수 있는 고유한 주소

URL의 구조

http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2

http - 제일 앞부분인 해당자원을 얻기 위해 어떤 통신규약, 즉 프로토콜

https - 좀 더 보안이 강화된 프로토콜

www.example.com - 호스트 주소,  IP주소(ex 74.125.24.101)를 문자형태로 바꾼것 = DNS

:80 -  포트 번호 (고유한 번호), 이를 통해서 만 자원이 오갈 수 있다.

path/to/myfile.html - 경로(path), 컴퓨터에 있는 파일의 경로와 비슷한 역할

?key1=value1&key2=value2 - 파라미터, 웹 서버에 전달할 문구(요청)

공백이 있으면 안된다.

URL? URI?

URI = Uniform Resource Identifier : 자원을 구분할 수 있는 유일한 식별자
URL = Uniform Resource Locator : 자원의 위치를 구별할 수 있는 고유한 주소

URN = Uniform Resource Name : 자원을 지칭하는 고유한 이름

URL (자원위치) +  URN (자원이름) = URI(자원 식별)

URL을 IP로 변환하는 DNS (Domain Name System)

DNS 는 우리가 입력한 웹사이트(도메인) 주소를 컴퓨가 이해할 수 있는 IP 주소로 변환 해주는 역할

Domain & IP

(ex) 지도 앱에서 장소명 (예술의 전당) 을 치면 위치(장소명이 위치한 주소, GPS 좌표)가 나오는 것

Domain : 장소명  

IP 주소 : 장소명이 위치한 주소 → 컴퓨터가 이해할 수 있는 IP 주소

한 웹 사이트의 IP주소가 (123.456.789.1) 라면  기억을 하기 어렵다

그래서 쉽게 접근할 수 있도록 호스트 이름이 생김. 이것이 도메인(www.example.com).

123.456.789.1 → www.example.com  

도메인의 구조

최상위 도메인이 com, net, org, edu, gov, mil, int 과 같은 일반 도메인인 경우

-2 단계에서 도메인 신청자가 원하는 이름을 사용

최상위 도메인이 국가 도메인인 경우

-  2단계 도메인은 기관을 분류(co, or, ac 등)하기 위해서 미리 정의된 이름을 사용

DNS ?

DNS : 도메인과 IP 주소를 서로 변환해주는 역할을 하는 시스템 , 변환 시스템

DNS 서버 (네임서버) : 변환 시스템을 운영하는 서버

DNS의 통신방법

Local DNS : 우리가 일반적으로 이용하는 인터넷 통신사의 DNS 서버

ROOT DNS : 최상위 도메인( 1차 도메인, .com .kr . org)을 관리하는 서버의 정보를 알려주는 역할

최상위 도메인 DNS : 최상위 도메인을 관리하는 서버 종류에 따라서 다르게 관리하고 있다. 예) com DNS, kr DNS, ..

• DNS 서버(Local DNS)에 해당 도메인에 대한 IP 주소가 없는 경우 설명

주소창에 google.com 이라는 도메인을 입력했을 시

1번 & 8번

1번 :  User  → ( www.google.com ) → Local DNS  

8번: IP 주소를 알고 있으면  Local DNS -> (74.125.24.101 )-> User

2번 & 3번

2번 : Local DNS → (www.google.com IP 주소를 아니?) → Root DNS

3번 : Root DNS → (모르겠는데. 내가 알려주는 com DNS 서버로 가볼래?) -> Local DNS

4번 & 5번

4번 : Local DNS → (www.google.com IP 주소를 아니?) → Com DNS

5번 : Com DNS → (모르겠는데. 내가 알려주는 .google.com DNS 서버로 가볼래?) -> Local DNS

6번 & 7번

6번 : Local DNS → (www.google.com IP 주소를 아니?) → google.com DNS

7번 : google.com DNS → (어 알아! 74.125.24.101 이야) →  Local DNS

8 번

Local DNS -> (74.125.24.101 )-> User

참고 자료

https://gigaline.com/okdomain/info/info-8.html

Network

그물처럼 서로 긴밀하게 연결된 것.

즉,  컴퓨터, 스마트폰, 노트북, IPTV 등 인터넷에 연결되는 다양한 기기들이 서로 연결되어 정보를 주고 받는것

LAN (Local Area Network)

물리적으로 가까운 영역에 있는 기기들이 서로 연결된 소규모 네트워크

WAN (World Area Network)

지역이나 국가등 물리적으로 넓은 영역에 있는 기기들을 서로 연결하는 광역 네트워크

여러 곳에 흩어진 소규모 네트워크가 서로 통신할 수있게 연결한 것 -> LAN 을 서로 연결한 것을 WAN

OSI 7계층

Open Systems Interconnection 7 : 통신이 일어나는 과정을 7단계로 구분시키고, 단계별 표준을 정의한 것

WHY?

많은 사람들이 사용할 때 문제가 생기지 않도록 하기위해서 서로 다른 시스템이 잘 연결(호환)될 수 있게 각 단계를 구별하고 이를 표준화 함.

이점

• 계층 내 장치나 통신 규약이나 프로토콜이 달라져도 통신을 할 수 있게됨.
• 처음보거나 새로 개발된 장치/프로토콜을 빠르게 예측고 이해가능
• 문제 발생시 해당 계층만 고칠수 있게 되어 유지및 관리도 수월해짐

TCP/IP 4 계층

현대 네트워크가 대부분 사용 하는 모델 => TCP/ IP 모델 혹은 인터넷 프로토콜 스위트(internet protocol suite)

두 모델이 계층을 다르게 나눈 이유

OSI 모델은 다른 기종의 컴퓨터끼리도 네트워크를 형성할 수 있게 역할별로 계층을 나누고 표준을 정함

TCP / IP 모델은 실제로 다른 컴퓨터들이 데이터를 주고받을 수 잇는 프로토콜을 만들어 실무에 적용

OSI 모델로 보는 데이터 전송