OSI 7 Layer

Moom2n·2024년 3월 25일

CS

목록 보기

3/11

L7 Application Layer

데이터를 사용자에게 전달하는 계층
하위 세 개의 계층(Host-to-Network, Internet, Transport)은 모두 데이터가 한 컴퓨터에서 다른 컴퓨터로 어떻게 전송되는지를 정의하는 데 협력한다.
Application layer은 데이터가 전송된 후에 어떻게 처리할지를 결정한다.
-- 예를 들어, HTTP와 같은 protocol은 웹 브라우저가 그래픽 이미지를 숫자의 긴 스트림이 아닌 그림으로 표시하도록 보장한다.
Application layer은 여러분의 프로그램의 네트워크 부분 대부분이 시간을 보내는 곳이다.
다양한 application layer protocol이 있다
-- 웹을 위한 HTTP
-- 이메일을 위한 SMTP, POP, IMAP
-- 파일 전송을 위한 FTP, FSP, TFTP
-- 파일 접근을 위한 NFS
-- 파일 공유를 위한 Gnutella와 BitTorrent
-- 음성 통신을 위한 Session Initiation Protocol (SIP) 및 Skype 등이 있다.
필요한 경우 고유한 application layer protocol을 정의할 수 있다.
-- Skype protocol은 기본적으로 P2P architecture를 기반으로 하며, 사용자 간의 음성 통화, 비디오 통화, 메시지 전송 등을 가능하게 한다.
-- Skype의 특성 및 보안 요구 사항을 충족하기 위해 개발되었다.
-- Skype만의 위한 비공개 protocol

- HTTP(Hyper Text Transfer Protocol)

> GET /index.html HTTP/1.1
> Host: servername

< HTTP/1.1 200 OK
< ....

L4 Transport Layer

Transport layer은 데이터 패킷이 전송 순서대로 받아지고 데이터가 손실되거나 손상되지 않도록 보장하는 역할을 한다. 패킷이 손실된 경우, 전송 계층은 송신자에게 패킷 재전송을 요청할 수 있다. IP 네트워크에서는 이를 각 데이터그램에 추가 정보를 포함하는 추가 헤더를 추가함으로써 구현한다.

이 수준에서는 두 가지 주요 프로토콜이 있다.

Transmission Control Protocol (TCP)이 있는데, 이는 높은 오버헤드 프로토콜로서 손실된 데이터나 손상된 데이터의 재전송 및 전송된 바이트의 순서대로 전달을 허용한다.
User Datagram Protocol (UDP)로, 수신자는 손상된 패킷을 감지할 수 있지만 패킷이 올바른 순서로 전달되는 것을 (또는 아예 전달되는 것을) 보장하지 않는다. 그러나 UDP는 종종 TCP보다 빠르다. TCP는 신뢰성 있는 프로토콜로, UDP는 신뢰성 없는 프로토콜이다. 나중에 신뢰성 없는 프로토콜이 앞서 이야기한 것보다 훨씬 유용하다는 것을 보게 될 것이다.
-- 신뢰성 있게 보냄. 순서도 맞춰주고, 데이타가 누락되지 않게 챙겨주고

- UDP

RFC768 User Datagram Protocol

checksum 정도만 제공
-- 보내는 패킷의 데이타가 전송도중 잘못 되지는 않았는지 정도만.
별 다른 기능이 없으므로, TCP 에 비해 상대적으로 빠를 가능성이 있음

- TCP

출발지 포트번호, 목적지 포트번호
세그먼트가 목적지에 도착하면, OS 는 목적지 포트번호로 애플리케이션(프로세스)을 식별
-- 해당 애플리케이션에 전달.

TCP 커넥션 맺기

TCP 데이터 재전송 1

수신측
-- 수신한 패킷의 ACK 를 전송
송신측
-- 특정 시간(타이머!)동안 보낸 패킷에 대한 ACK 패킷이 없는 경우 retransmission.
-- 송신 패킷이 전달이 안된 경우.
-- 수신 입장에선 적장한 패킷을 받음. 정상 케이스 -
-- 수신(ACK) 패킷이 전달이 안된 경우.
수신 입장에선 같은 패킷을 두 번 받음. 같은 패킷에 대해 다시 ACK

TCP 데이타 재전송 2

수신측
-- 수신한 패킷의 ACK 를 전송
-- 중간 누락 패킷이 있는 경우, 순서가 맞는 마지막 패킷의 ACK 를 계속 전송
송신측
-- Duplicated ACK (DUP ACK) 가 3번오면, 재전송 (fast restransmission)

TCP 커넥션 끊기

TCP 상태도

Congestion Control

- Well-known 포트

같은 일을 하는 서버가 매번 다른 포트를 사용하면 통신하기 어려울 것.
프로토콜에 고정 포트번호를 부여하는 경우 (꼭 그래야할 필요는 없음)
HTTP 80 - 브라우저에 주소창에 명시하지 않아도 http 프로토콜은 80 포트를 사용
http://naver.com , http://naver.com:80
DNS 53
SMTP 25

L3 Network Layer

데이타를 전송. 경로를 결정
어떻게 데이타를 보낼 것인가?

네트워크의 다음 계층은 여러분이 관심을 가지게 될 첫 번째 계층이며, OSI 모델에서는 네트워크 계층이라고 더 일반적인 이름으로 불립니다. 네트워크 계층 프로토콜은 데이터의 비트와 바이트가 패킷이라고 불리는 더 큰 그룹으로 어떻게 구성되는지, 서로 다른 기기가 서로를 찾는 데 사용되는 주소 지정 방식을 정의합니다. 인터넷 프로토콜 (IP)은 전 세계에서 가장 널리 사용되는 네트워크 계층 프로토콜이며, Java가 이해하는 유일한 네트워크 계층 프로토콜입니다.

사실, 이것은 두 가지 프로토콜입니다. IPv4는 32비트 주소를 사용하며, IPv6는 128비트 주소를 사용하며 경로 설정을 돕는 몇 가지 다른 기술 기능을 추가합니다. 이 글을 작성하는 시점에서 IPv4는 인터넷 트래픽의 90% 이상을 여전히 차지하고 있지만, IPv6는 빠르게 증가하고 다음 판의 이 책이 나오기 전에 IPv4를 앞서갈 가능성이 높습니다. 이 두 가지는 매우 다른 네트워크 프로토콜이며 특별한 게이트웨이나 터널링 프로토콜 없이 동일한 네트워크에서 상호 운용하지 않지만, Java는 거의 모든 차이점을 숨깁니다.

IPv4와 IPv6 모두 데이터가 데이터그램이라고 불리는 패킷을 통해 인터넷 계층을 통해 전송됩니다. 각 IPv4 데이터그램에는 20~60바이트 길이의 헤더와 최대 65,515바이트의 데이터를 포함하는 페이로드가 있습니다. (실제로 대부분의 IPv4 데이터그램은 몇십 바이트에서 조금 더 8킬로바이트를 넘지 않는 작은 크기를 가지고 있습니다.) IPv6 데이터그램에는 더 큰 헤더와 최대 4기가바이트의 데이터가 포함될 수 있습니다.

- IPv4

1 	ICMP 	Internet Control Message 		[RFC792]
2 	IGMP 	Internet Group Management 		[RFC1112]
6 	TCP 	Transmission Control 		[RFC-ietf-tcpm-rfc793bis-28]
8 	EGP 	Exterior Gateway Protocol 		[RFC888][David_Mills]
9 	IGP 	any private interior gateway (used by Cisco for their IGRP) 		[Internet_Assigned_Numbers_Authority]
17 	UDP 	User Datagram 		[RFC768][Jon_Postel]

IPv4 Address

223.1.1.1

Subnet mask

네트워크ID를 표시 하기 위해 사용

Subnet

라우터를 통하지 않고 갈 수 있는 네트워크
223.1.1 , 223.1.2 , 223.1.3

라우터

포워딩
-- 데이타를 전달한다.
-- 포워딩 테이블을 참조하여 데이타를 전달.
-- 네트웍 ID 기준
라우팅
-- 포워딩 테이블을 만든다.
라우팅 테이블

- NAT (Network Address Translation)

서버 운영이 불가능
서로 다른 NAT 환경의 두 호스트가 직접 통신하는 것은 어려움

- DHCP (Dynamic Host Control Protocol)

개별 호스트에 적절한 네트워크 정보를 설정하기 위한 프로토콜

- ICMP

네트워크 상태를 보고하기 위한 메시지
TTL 넘어가는 경우, source 에 알려줌

- 라우팅 알고리즘

L2 Data Link Layer

Physical Addressing
NIC Network Interface Card
다음 한 홉만 해결!
공유하는 전송 미디어에 어떻게 데이타를 잘 보낼 수 있을까?
-- 공유하는 전송 미디어에 데이타를 여러 명이 동시에 보내면 안됨. 노이즈. 쓸 수 없는 데이타가 됨.

- MAC 프로토콜

CSMA/CD (Carrier Sence Multiple Access / Collision Detection)

누가 이야기하는지 들어보다가 (Carrier Sence) 이야기 안하는 것 같으면,
데이타를 보냄 - 보내는 동안 다른 데이타가 내게 도착하면 충돌이라고 판단.
충돌이 감지되면 (Collision Detection) 보내던 데이타를 끊고, 랜덤하게 쉬었다가 재전송

- Ethernet 토폴로지

- 스위치

네트워크 관점에서 스위치는 보이지 않는 존재
-- IP 도 없고,
-- MAC 도 없고
하지만, L2, L3, L4 스위치등 각 layer별로 처리하는 스위치가 사용됨
-- L2 스위치는 MAC 주소를 가지고 있으면서 해당 포트로 패킷을 전달
-- L3 스위치는 IP 주소를 가지고 있으면서 해당 포트로 패킷을 전달(Router)
L3 Switch
-- L3 스위치는 라우팅 기능을 수행할 수 있는 네트워크 스위치
-- OSI model의 네트워크 계층(layer 3계에서 작동하며 IP 주소를 사용하여 라우팅 결정
-- MAC address를 기반으로만 트래픽을 전달하는 기존 스위치(L2 switch)와 달리 L3 스위치는 서로 다른 VLAN 또는 서브넷 간에 트래픽을 라우팅할 수 있음
이점
-- 브로드캐스트 트래픽을 줄여 네트워크 성능 향
-- 네트워크를 더 작은 subnet으로 분할하고 VLAN을 사용하면 브로드캐스트 트래픽이 각 subnet 내에 포함되어 정체가 줄어들고 전반적인 효율성 향상
-- OSPF, BGP 등 여러 프로토콜을 지원하므로 기업 네트워크, 데이터 센터, 서비스 제공업체 네트워크 등 다양한 환경에서 사용 가능

HTTP (Hypertext Transfer Protocol)

Hypertext : Hyperlink를 통해 한 문서에서 다른 문서로 즉시 접근할 수 있는 텍스트
Web의 자원 위치에 접근하는 protocol
HyperText (HyperMedia)를 클라이언트와 서버 사이에 주고 받을 수 있게 정의한 프로토콜
TCP/IP 프로토콜 위에서 동작하는 Text Based 프로토콜
-- 사람이 눈으로 보고 이해 가능!

- WWW (World Wide Web)

Web 브라우저가 Web Server의 HTML로 기술된 리소스를 URL을 통해 요청하여 HTTP를 사용하여 받아서 표현하는 것

- HTML (HyperText Markup Language)

자원들 사이를 쉽게 항해 할 수 있는 언어

<!DOCTYPE html>
<html>
    <head>
        <title>Welcome, NHN Academy</title>
    </head>
    <body>
        <h3> Welcome </h3>
        <p> Hello, NHN Academy. </p>
        <p>
            <a href="http://nhnacademy.com">
                <img src="logo.png" />
            </a>
        </p>
    </body>
</html>

- URL (Uniform Resource Locator)

통일된 웹 자원(Resource)의 위치 지정 방법

<scheme>://[<username>:<password>@]<host>[:<port>]<Request-URI>[?<query>#<fragment>]

Ex).

  https://nhnent.dooray.com/project/to?userWorkflowClass=registered,working

scheme: https , http , ftp , file (= protocol)
host: nhnent.dooray.com (= server)
request URI: /project/to
query: userWorkflowClass=registered,working

- 기본 작동 원리

요청(Request): 사용자가 웹 브라우저를 통해 특정 웹 페이지에 접근하려고 할 때, 브라우저는 해당 서버에 HTTP 요청을 보냅니다. 이 요청에는 URL, 요청 방식(GET, POST 등), 헤더 정보 등이 포함됩니다.

GET /welcome.html HTTP/1.1
Host: test-vm.com:3000
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
DNT: 1
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: ko
If-Modified-Since: Sat, 15 Jan 2022 18:23:48 GMT

응답(Response): 서버는 받은 요청을 처리한 후, 요청된 자원과 상태 코드(200, 404 등), 응답 헤더 등을 포함한 HTTP 응답을 클라이언트에게 전송합니다.

HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/2.7.13
Date: Sat, 15 Jan 2022 19:09:33 GMT
Content-type: text/html
Content-Length: 358
Last-Modified: Sat, 15 Jan 2022 18:23:48 GMT

<!DOCTYPE html>
<html>
    <head>
        <title>Welcome, NHN Academy</title>
    </head>
    <body>
        <h3> Welcome </h3>
        <p> Hello, NHN Academy. </p>
        <p>
            <a href="http://nhnacademy.com">
                <img src="logo.png" />
            </a>
        </p>
    </body>
</html>

상태 코드
-- 1xx: 정보 제공
-- 2xx: 성공
-- 3xx: 리다이렉션
-- 4xx: 클라이언트의 오류
-- 5xx: 서버의 오류

- GET vs POST

GET

-- 리소스를 요청하기 위한 메서드

<!DOCTYPE html>
<html>
    <head>
        <title>Welcome, NHN Academy</title>
    </head>
    <body>
        <h3> Welcome </h3>
        <form action="./welcome.html" method=GET >
          name: <br/>
          <input type="text"     name="name"   > <br/>
          content: <br/>
          <input type="textarea" name="content"> <br/>
          <input type="submit"   name="send" value="send">
        </form>
    </body>
</html>

GET /welcome.html?name=TEST-NAME&content=TEST-CONTENT&send=send HTTP/1.1
Host: test-vm.com:3000
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
DNT: 1
Referer: http://test-vm.com:3000/form-get1.html
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: ko
If-Modified-Since: Sat, 15 Jan 2022 23:30:56 GMT

POST

-- 서버에 입력 데이타를 전송하기 위한 메서드
-- 주로 HTML 폼을 사용하기 위하여 많이 사용됨

<!DOCTYPE html>
<html>
    <head>
        <title>Welcome, NHN Academy</title>
    </head>
    <body>
        <h3> Welcome </h3>
        <form action="./welcome.html" method=POST>
          name: <br/>
          <input type="text"     name="name"   ><br/>
          content: <br/>
          <input type="textarea" name="content"><br/>
          <input type="submit"   name="send" value="send">
        </form>
    </body>
</html>

POST /welcome.html HTTP/1.1
Host: test-vm.com:3000
Connection: keep-alive
Content-Length: 45
Cache-Control: max-age=0
Origin: http://test-vm.com
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
DNT: 1
Referer: http://test-vm.com:3000/form-post1.html
Accept-Encoding: gzip, deflate, br
Accept-Language: ko

name=TEST-NAME&content=TEST-CONTENT&send=send

차이점

요청 주소:
GET: /welcome.html?name=TEST-NAME&content=TEST-CONTENT&send=send
POST: /welcome.html

헤더
GET: Content-Type , Content-Length 헤더 없음.
POST: Content-Type: application/x-www-form-urlencoded , Content-Length: 45

- 인증, 쿠키, 세션

쿠키

RFC6265 HTTP State Management Mechanism
서버가 클라이언트에 붙여둔 일종의 스티커(?)
서버가 클라이언트에게 쿠키를 세팅 요청(Set-Cookie:) 하면 (스티커를 붙이면),
클라이언트는 이후 서버에게 보내는 요청 헤더에 쿠키(Cookie: )를 표시해서 전송 (스티커를 붙인 채 다시 돌아와야 함)

종류

Session Cookie(세션 쿠키)
-- 사용자가 브라우저를 사용하는 동안만 유효함.
-- 브라우저는 사용자가 브라우저를 사용하는 동안 Cookie 정보를 서버로 전달.
Persistent Cookie(지속 쿠키)
-- 사용자가 브라우저를 종료하더라도 유지되는 쿠키
-- Expires 혹은 Max-Age 가 같이 설정되는 쿠키

인증 HTTPS (HTTP over SSL/TLS)

대칭키 암호화 알고리즘 (Symetric Encryption Algorithm)
비대칭키 암호화 알고리즘 (Asymetric Encryption Algorithm)
키 교환 알고리즘 (Key Exchange Algorithm)
인증서 (Certificate)
인증기관 (Certificate Authority)

Moom2n

이전 포스트

CPU 의 Hz

다음 포스트