'Computer Science/Web' 카테고리의 글 목록 (2 Page)

📌 김영한 님의 "모든 개발자를 위한 HTTP 웹 기본 지식" 강의 듣고 정리

📍HTTP (Hyper Text Transfer Protocol)

'HTTP'는 다양한 환경에서 여러 기기가 서로 통신을 주고 받을 수 있게 만든 일종의 규칙이다.

예를 들어 내(가 이런 데이터를 요청하면 너는 이런 데이터를 반환하라는 식의 통신 규칙인 것이다.

* 문서간의 링크를 통해 연결할 수 있는 html을 전송하는 프로토콜로 시작했다. 그러나 현재는!

HTML, TEXT
이미지, 음성, 영상, 파일
JSON, XML (API)

거의 모든 형태의 데이터를 전송 가능해졌고, 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용하고 있다.

* HTTP 역사

HTTP/0.9 : 1991년 / GET 메서드만 지원, HTTP 헤더 없음
HTTP/1.0 : 1996년 / 메서드와 헤더 추가
HTTP/1.1 : 1997년 / 현재에 가장 많이 사용하는 버전 (RFC문서 : 2068 > 2616 > 7230~7235)
HTTP/2 : 2015년 / 성능 개선
HTTP/3 : 진행중 / TCP대신 UDP 사용, 성능개선

* 기반 프로토콜

TCP : HTTP/1.1 , HTTP/2
UDP : HTTP/3

HTTP/2 , HTTP/3 도 사용이 점점 증가하고 있다.

📍클라이언트 서버 구조

HTTP는 Request 와 Response의 구조
클라이언트는 요청을 보내고 서버의 응답 대기
서버는 요청에 대한 결과를 응답

* 왜 이렇게 분리할까?

개념적으로 분리함으로써 비지니스 로직과 데이터는 서버에게 UI, 사용성 등은 클라이언트에게 집중시켜 독립적으로 진화가 가능해진다.

📍Stateful, Stateless

HTTP의 중요한 특징 중 하나는 무상태 프로토콜을 지향한다.

* 무상태성(Stateless)이란?

클라이언트가 하는 요청에 대해 서버는 응답만 할 뿐 이전 상태에 대한 정보를 보존하지 않는다.

이전에 무엇을 요청했는 지에 따라 결과 값이 달라지는 등의 변화는 없다. 철저하게 매번 요청 값에 대한 것만을 응답한다.

상태 유지는 응답 서버가 바뀌게 되면 다른 서버에도 알려야 하며, 중간에 서버가 장애가 나면 처음부터 해야한다.

무상태는 응답 서버를 바꿔도 응답이 가능하며 이는 중간에 서버가 장애가 나도 다른 응답 서버가 계속할 수 있다. 이는 무한한 서버 증설이 가능케 한다. (서버의 수평 확장(Scale Out)이 높다 )

하지만 이것도 한계가 있다. 모든 것을 무상태로 설계하는 것은 힘들기 때문이다.

그래서 상태 유지는 최소한 만으로 사용하며 최대한 무상태 성을 유지하기 위해 노력한다.

보통 상태 유지 가장 대표적인 예는 로그인한 사용자의 경우 로그인 상태를 서버에 유지하는 것이다. 일반적으로 이는 브라우저 쿠키와 서버 세션등을 사용한다.

그리고 한가지 단점이 상태를 유지하지 않기 때문에 매번 보내야 하는 정보량이 더 많다는 단점이 있다.

📍비 연결성 (Connectionless)

연결을 유지하는 동안 서버는 이를 유지하기 위해 서버 자원을 소모하게 된다.

연결을 유지하지 않으면 필요한 것만을 요청하고 응답받고 나면 연결을 끊어 최소한의 자원을 사용할 수 있다.

* HTTP는?

HTTP는 기본이 연결을 유지하지 않는 모델
일반적으로 초 단위의 이하의 빠른 속도로 응답
서버 자원을 매우 효율적으로 사용

* 비 연결성의 한계는?

TCP/IP 연결을 계속 새로 맺어야한다. 연결시 3 way handshake 단계가 반복되므로 그만큼 시간이 추가된다
웹 브라우저로 사이트 요청하면 수 많은 자원들이 한꺼번에 다운받아지는 데, 중간에 끊기면 처음부터 다시 다 다운받아야한다.
지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결 (연결 유지 될때
HTTP/2와 HTTP/3에서 최적화

**** HTTP 지속 연결

자원 하나를 요청했을 때 이와 묶여있는 모든 자원을 요청하기 위해 연결을 유지한 상태

클라이언트의 요청 또는 TimeOut 전까지는 연결이 열려있어 클라이언트가 자원을 연속적으로 요청할 수 있고 이에 서버는 연속적으로 응답할 수 있다 (파이프 라이닝)

연결 시도 횟수가 줄어들어 효율적이다.

HTTP/1.1 기준 달리 명시 되어있지 않으면 모든 연결은 지속 연결로 간주된다. 서버마다 Timout이 존재한다.

📍HTTP 메시지

* HTTP 메시지 구조 설명

- HTTP 시작라인

요청	HTTP 메서드 : 종류 : GET, POST, PUT, DELETE 등으로 서버가 수행해야 할 동작 지정 요청 대상 : /절대경로[?쿼리] HTTP-version
응답	HTTP-version HTTP 상태코드 : 요청 성공, 실패를 나타냄 이유 문구 : 사람이 이해할 수 있는 짧은 상태 코드 설명 글

- HTTP 헤더

HTTP 전송에 필요한 모든 부가정보를 담는다.
표준 헤더가 존재한다.
필요시 임의 헤더가 추가 가능하다.

- HTTP 메시지 바디

실제 전송할 데이터
byte로 표현할 수 있는 모든 데이터 전송 가능

* HTTP 요청 메시지 예제

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

* HTTP 응답 메시지 예제

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423

<html>
<body>...</body>
</html>

* HTTP 메시지 구조로 예시 파악

- 요청 메시지

start-line 시작 라인	GET /search?q=hello&hl=ko HTTP/1.1
header 헤더	Host: www.google.com
empty line 공백 라인 (CRLF)
message body

시작 라인 :

method	SP(공백)	request-target	SP(공백)	HTTP-version	CRLF(엔터)
GET		/search?q=hello&hl=ko		HTTP/1.1

HTTP 헤더 :

field-name:	OWS(띄어쓰기 허용)	field-value	OWS(띄어쓰기 허용)
Host:		www.google.com

- 응답 메시지

start-line 시작 라인	HTTP/1.1 200 OK
header 헤더	Content-Type: text/html;charset=UTF-8 Content-Length: 3423
empty line 공백 라인 (CRLF)
message body	<html> <body>...</body> </html>

시작 라인 :

HTTP-version	SP(공백)	status-code	SP(공백)	reason-phrase	CRLF
HTTP/1.1		200		OK

HTTP 헤더 :

field-name:	OWS(띄어쓰기 허용)	field-value	OWS(띄어쓰기 허용)
Content-Type: Content-Length:		text/html;charset=UTF-8 3423

저작자표시 (새창열림)

'Computer Science > Web' 카테고리의 다른 글

HTTP 웹 지식 - HTTP 메서드 활용 (0)	2023.03.08
HTTP 웹 지식 - HTTP API를 만들어보자 (0)	2023.03.07
HTTP 웹 지식 - URI와 웹 브라우저 요청 흐름 (0)	2023.03.06
HTTP 웹 지식 - 인터넷 네트워크 (0)	2023.03.06
HTTPS (0)	2023.01.14

📌 김영한 님의 "모든 개발자를 위한 HTTP 웹 기본 지식" 강의 듣고 정리

📍URI (Uniform Resource Identifier)

* URI? URL? URN? 많이 묶여서 보이는 단어 3가지

URI : 자원을 식별하는 식별자. URI는 locater(URL), Name(URN) 또는 둘다 추가로 분류 될 수 있다.
URL : 리소스의 위치 지정, 가변성 有
URN : 리소스의 이름 부여, 가변성 無, 이름만으로 리소스를 찾는 방법이 보편화 되있지 않다.

URL(위)과 URN(아래)의 예시

* URI의 뜻

Uniform : 리소스를 식별하는 통일된 방식
Resource : 자원, URI로 식별할 수 있는 모든 것 (자원에 제한 없음)
Identifier : 다른 항목과 구분하는데 필요한 정보

* URL

scheme://	[userinfo@]	host	[:port]	[/path]	[?query]	[#fragment]
https://		www.google.com	:443	/search	q=hello&hl=ko
프로토콜		호스트명	포트번호	패스	쿼리 파라미터

- scheme (스키마)

scheme엔 주로 프로토콜 사용

프로토콜 : 어떤 방식으로 자원에 접근할 것인가 약속한 규칙

- userinfo@

URL에 사용자정보를 포함에 인증하지만 거의 사용하지 않는다.

- host

호스트명에는 도메인명 또는 IP주소를 직접 사용 가능하다

- port

접속 포트로 일반적으로 생략되며, 생략시 http는 80, https는 443 이 생략된다.

- path

리소스 경로로 계층구조로 구성되어있다.

- query

key=value 형태로 ?로 시작하며 &으로 추가가 가능하다.

query parameter, query string(문자로만 제공하기 때문) 으로도 불린다.

- fragment

html 내부 북마크 등에 사용하며 서버에 전달되지 않는 내용

📍웹 브라우저 요청 흐름

1. 웹 브라우저가 URL를 전송

2. DNS에서 도메인 명을 질의하여 IP를 찾아온다 그리고 포트 정보 까지 찾는다.

3. HTTP 요청 메세지 생성

* HTTP 요청 메세지 예시

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

* HTTP 메시지 전송

1. 웹브라우저가 HTTP 메시지 생성

2. SOCKET 라이브러리를 통해 전달하는데 IP와 포트 정보를 가지고 TCP의 3 way handshake를 통해 접속하려는 서버와 연결하고, 데이터를 전달

4. IP와 Port 정보가 있는 TCP/IP 패킷을 씌운다.

5. 그리고 네트워크 인터페이스 계층을 지나 인터넷 망으로 나간다. 수많은 노드를 거쳐 목적지에 도착

6. 요청 패킷에서 TCP/IP 패킷을 벗겨내어 안의 내용을 해석하고 요청을 처리한다.

7. 서버에서는 응답 메시지를 만든다.

8. 클라이언트가 했던것과 마찬가지로 2~5 과정을 거쳐 클라이언트에 패킷이 도착

9. 패킷을 벗겨내어 응답 메시지를 해석해 필요 응답 값에 대한 처리를 진행한다.

저작자표시 (새창열림)

'Computer Science > Web' 카테고리의 다른 글

HTTP 웹 지식 - HTTP API를 만들어보자 (0)	2023.03.07
HTTP 웹 지식 - 모든 것이 HTTP (0)	2023.03.06
HTTP 웹 지식 - 인터넷 네트워크 (0)	2023.03.06
HTTPS (0)	2023.01.14
XML (0)	2022.12.28

📌 김영한 님의 "모든 개발자를 위한 HTTP 웹 기본 지식" 강의 듣고 정리

📍인터넷 통신

- 인터넷 상에서 컴퓨터 둘은 어떻게 통신하나요?

메시지를 보내야하는 대상이 너무 멀리 있다면 인터넷 망을 통해서 메시지를 전달해야 한다.

하지만 인터넷 망은 매우 복잡해서 수많은 노드들이 사이에 존재하여 이를 거쳐야 한다.

그럼 도대체 어떤 규칙으로 목적지까지 안전하게 전달되는 걸까?

📍IP ( Internet Protocol )

현실세계에서도 편지를 주고 받을 때 주소가 존재하듯이 인터넷 상에도 주소가 존재한다. 그게 바로 IP주소다.

IP 역할 : 지정한 IP 주소로 데이터를 전달. 이때, 패킷(Packet)이라는 통신 단위로 데이터를 전달한다

* 클라이언트 패킷 전송

데이터를 전송하려는 클라이언트에서 출발지의 IP와 목적지의 IP 등의 정보를 붙여 데이터를 IP 패킷으로 만들어 인터넷에 던지면 인터넷 망의 모든 서버(노드)들은 이 IP 규약을 따르고 있기 때문에 이 주소를 찾아 계속 서로 던져주게 된다. 이런 식으로 던지다가 결국 최종 목적지에 다다르게 된다.

* 서버 패킷 전송

서버 측도 동일하다. 하지만 인터넷 망이 복잡하므로 받은 루트와 보낸 루트가 동일하지 않을 수 있다.

하지만 이런 IP 프로토콜에 한계가 있다.

비연결성 : 패킷을 받을 대상이 없거나 서비스 불능이어도 패킷을 전송해버린다.
비신뢰성 : 중간에 패킷이 사라져도, 패킷이 순서대로 가지 않더라도 해결이 안된다.
프로그램 구분 불가능 : 같은 IP를 사용하는 서버안의 프로그램끼리 구분하지 못한다.

이런 문제점을 해결하기 위해 나온 것이 TCP 이다.

📍TCP , UDP

인터넷 프로토콜 스택(TCP/IP Protocol)의 4계층은 아래와 같다.

애플리케이션 계층(Application Layer)	HTTP, FTP, telnet, DHCP, TFTP, SMTP, DNS, SNMP 등
전송 계층 (Transfer Layer)	TCP, UDP
인터넷 계층 (Internet Layer)	IP, ARP, RARP, ICMP
네트워크 인터페이스 계층 (Network Interface Layer 또는 Network Access Layer)

TCP, UDP는 IP 위에서 IP 기능을 보완한다.

메세지가 전달되는 과정은 아래와 같다.

1. 프로그램이 Hello, world! 메시지 생성하면

2. SOCKET 라이브러리를 통해 OS 계층으로 전달

3. 메시지 정보에 TCP 정보 씌운다(TCP 세그먼트). 그리고 IP계층으로 보내면

4. TCP 세그먼트에 IP와 관련한 데이터를 씌워 IP 패킷으로 생성

5. 그리고 나서 네트워크 인터페이스를 통해 LAN카드로 나가는 데, Ethernet Frame(이더넷 프레임 / 물리적 정보 포함)이 최종적으로 씌워져 나가게 된다.

- 패킷 (Packet) 이란? Package + Bucket

- IP 패킷 정보

출발지 IP, 목적지 IP, 등

- TCP 세그먼트 정보

출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등

* TCP (전송 제어 프로토콜 / Transmission Control Protocol)

신뢰할 수 있는 프로토콜로 현재 대부분 TCP 사용
연결지향 (연결을 먼저) - TCP 3 way handshake (가상연결 / 논리적 연결)
데이터 전달이 보장 (데이터를 보내면 이에 대한 응답을 보냄)
순서 보장 (중간에 잘못보낸다면 잘못보낸 순서부터 재전송)

- TCP 3 way handshake

SYN (접속 요청) , ACK(요청 수락 , 마지막 ACK에서 데이터도 전송 가능)

클라이언트가 서버에 SYN패킷으로 요청을 보내고 응답을 기다리는 SYN_SENT 상태가 된다.
서버는 SYN 요청을 받아 클라이언트에게 SYN / ACK 패킷을 보내고 응답을 기다리는 SYN_RECEIVED 상태로 기다린다.
마지막으로 클라이언트가 서버로부터 응답을 받아 ACK 패킷을 보내면 서버의 상태가 ESTEBLISHED가 되어 연결이 수립되고 데이터가 오고 가게 된다.

- TCP 순서 보장 방법

SEQ(Sequence), ACK(Acknowledge)로 수신 데이터 순서(offset)을 확인하고 누락/지연 패킷에 대한 재전송 알고리즘을 제공해 IP를 보완

• SEQ : 현 연결에서 현재까지 송신한 데이터 총 크기(바이트 단위)이자 순서 번호(Offset). 수신 측에서는 이걸보고 상대방이 지금까지 나에게 보낸 데이터 총량을 알 수 있다. 그리고 SEQ번호는 전체 데이터 상의 위치 번호와 같으므로 데이터 순서를 맞추는데 사용된다.

• ACK : 현 연결에서 현재까지 누락 없이 수신한 데이터 총 크기(바이트단위)이자 다음 수신을 원하는 SEQ 번호, 상대방이 누락 없이 받은 데이터 총량을 알 수 있다. 공식은 SEQ + (Data Size) 이다. 누락 발생 시 재전송해야 하는 SEQ 번호를 알 수 있다. 재전송은 상대방이 계속(마지막)에 보내오는 ACK 번호와 일치하는 SEQ 번호의 데이터를 전송하면 된다.

계속 동일한 ACK가 오는 걸 중복 ACK라 하는데, 송신측에서 다른 세그먼트를 보내도 중복 ACK가 3회 이상이면 송신 측에서 중간에 누락된 것으로 판단하게 되는데 해당 ACK 번호와 일치하는 SEQ 데이터 세그먼트를 재전송하게 된다. 재전송 발생 여부는 장비 불량이나 네트워크 이상, 장비 설정 이상 등을 유추할 수 있는 단서가 되기 때문에 체크요소가 된다.

출처: https://evan-moon.github.io/2019/11/26/tcp-congestion-control/

https://packetlife.net/blog/2010/jun/7/understanding-tcp-sequence-acknowledgment-numbers/

* Number 뒤에 (raw)인건 실제 세그먼트 데이터 번호고 (raw) 없는 건 보기 편하게 가공된 번호

* Window는 수신측에서 처리할 수 있는 데이터 양

* flags는 flags 들을 한자리 수처럼 여겨 16비트 통으로 표현

* Data Size가 0이라면 같은 ACK을 반복하게 된다. 이 것을 방지해서 받은 패킷의 Data Size가 0이라면 Sequnce 번호에 1을 더한 값을 ACK으로 설정

* 먼저 3 way handshake

* 데이터 전송

수신했다는 표시로 다음 Acknowledge Number로 다음 차례를 알려준다.

* 아래글에 위 그림이랑 최대 세그먼트 크기 초과해서 둘로 나누는 방식도 보여줌

Understanding TCP Seq & Ack Numbers [Packet-by-Packet] | GoLinuxCloud

Reliability is one of TCPs strong feature. TCP ensures that all packets one end sends will be delivered to the other end, keeping track of which packets have

www.golinuxcloud.com

* UDP (User Datagram Protocol)

기능이 거의 없어 하얀 도화지에 비유
TCP의 연결지향 (3 way handshake) , 데이터 전달 보장, 순서 보장 모두 안됨
그러나 단순하고 빠름! Custom이 가능하기 때문에 더 최적화가 가능함!
IP와 다른건 PORT와 체크섬(데이터가 맞는지) 기능 추가되며 애플리케이션에서 추가 작업 필요하다.

📍PORT

하나의 IP에 여러 프로그램이 있다면 들어오는 데이터가 어디 프로그램에 필요한 데이터인지 어떻게 구분할까?

같은 IP내에서 프로세스를 구분하는 것이 PORT다. IP는 아파트 PORT는 몇동 몇호!

0 ~ 65535 할당 가능 ( 0 ~ 1023 은 잘 알려져있어 사용 권장 X )
FTP (20, 21) , TELNET (23) , HTTP (80) , HTTPS (443)

📍DNS ( Domain Name Server)

IP는 기억하기도 어렵고 IP가 변하는 경우도 있다.

인터넷 망의 전화번호부
도메인 명을 IP주소로 변환

* DNS 사용 과정

1. 도메인 명을 검색 google.com

2. DNS 서버가 이를 받아 해당 도메인에 맞는 IP주소를 응답

3. 클라이언트는 응답받은 IP주소로 접속

저작자표시 (새창열림)

'Computer Science > Web' 카테고리의 다른 글

HTTP 웹 지식 - 모든 것이 HTTP (0)	2023.03.06
HTTP 웹 지식 - URI와 웹 브라우저 요청 흐름 (0)	2023.03.06
HTTPS (0)	2023.01.14
XML (0)	2022.12.28
OAuth 2.0 (2)	2022.12.15

📌 실전 프로젝트때 HTTPS로 발생하는 문제가 많아 도움이 될까 공부해본다.

HTTPS

📍HTTP + S (Secure)

의 의미로 기존 HTTP보다 보안성을 더한 프로토콜이다.

📍 그럼 HTTP는?

Hypertext Transfer Protocol로 풀이하자면 하이퍼 텍스트를 전송하기 위한 프로토콜로 서로 다른 시스템들 간에 통신을 가능하게 하는 가장 기본적인 프로토콜이다.

하지만 HTTP에는 한가지 문제점이 있는데, 바로 서버에서 브라우저로 전송되는 정보가 암호화 되지 않는다는 것이다.

이는 중간에 탈취를 당한다면 그대로 정보가 노출되어 버리는 것이다.

그래서 이런 문제를 보완하기 위해 나온 것이 바로 HTTPS다.

HTTPS는 SSL(Secure Sockets Layer / 보안 소켓 계층) 또는 TLS(Transport Layer Security : SSL이 발전하여 이름이 변경된 것으로 거의 같은 단어로 사용하고 있다)를 사용해 서버와 브라우저 간에 암호화된 연결을 시켜주어 정보가 도난당하는 것을 막아준다. 보는 페이지의 암호화 키를 특정 사용자에게만 알게해 오가는 데이터를 암호화 시키는 것이다.

📍 그럼 암호화는 어떤 방식으로 할까?

두가지 방식을 혼합하여 사용한다.

두가지 방식을 먼저 소개하자면,

비대칭키 (공개키)

서로 "다른 키"로 가지고 각각 서로 암호화하고 각자가 가진키로 복호화하는 방식이다. 둘 중 하나는 공개키(Public Key)라고 하며 데이터 암호화 시에 사용하고, 나머지 하나는 개인키(Private Key)라고 하여 복호화시에 사용한다. 공개키로 암호화한 정보는 오직 개인키로만 복호화 할 수 있기 때문에 공개키는 누가 가지고 있더라도 상관 없다. 따라서 키를 전송하는 과정에서 중간 탈취가 이루어져도 전혀 문제가 되지 않는다. 하지만 대칭키와 달리 암호화, 복호화의 연산이 더 어렵고 복잡해 시간이 더 드는 단점이 있다.

대칭키

서버와 클라이언트가 각각 "같은 키"를 가지고 서로 암호화와 복호화 하는 방식이다. 그래서 키를 가지고 있는 누구든지 원래 정보로 복호화가 가능하고 빠르며 쉽다. 하지만 같은 키를 가지기 위해 전송하는 과정에서 탈취를 당하면 해커도 대칭키를 이용해 복호화할 수 있다는 단점이 있다.

둘다 쓴다는 말에서 두종류 중 하나를 선택한다는 착각을 할 수도 있지만 (내가 그랬다) 정확하게는 두가지를 "혼합"해 사용하며 서로의 단점을 보완하여 최적의 방법으로 사용한다.

그 최적의 방법은 통신과정을 통해 알아보자.

📍 SSL 기본 통신과정

A가 B로 접속 요청을 보내면 B는 A에게 공개키를 전달한다. (공개키 방식)

그러면 A는 받은 공개키를 가지고 자신의 대칭키를 암호화 한다. (공개키 방식)

A는 암호화한 대칭키를 B에게 보낸다

B는 암호화한 대칭키를 받아 자신의 개인키로 복호화 한다. (공개키 방식)

이제부터는 복호화한 대칭키를 가지고 A와 통신을 이어간다 (대칭키 방식)

즉, 서로 같은 키(대칭키)를 갖기위해 처음 연결 때에만 공개키 방식을 사용하고, 이후 서로 대칭키를 갖은 순간부터는 대칭키만을 이용해 쉽고 빠르게 통신한다.

그럼 이렇게 통신하는 과정은 알았다. 그래서 이걸 어떻게 적용할 수 있을까?

📍 HTTPS 적용 방법

SSL방식을 적용하려면 인증서를 발급받아 서버에 적용시켜야 한다. 이러한 인증서는 이 서버가 안전한 서버인지 사용자에게 알려주는 역할을 한다. 이러한 인증서를 발급해주는 인증기관, CA(Certificate Authority)라고 하며, 우리 프로젝트에서는 AWS의 Certificate Manager을 이용해 발급받았다.

인증서를 받으려는 사이트는 자신의 정보와 공개키를 CA에게 제공하고 CA는 이를 검증한 후 인증기관의 개인키로 암호화한 인증서를 발급해 준다. 그리고 나서 CA는 이 공개키를 웹브라우저 그 자체에 제공한다. 웹브라우저라는 말에 사이트를 이용하는 클라이언트들에게 알린다는 건가? 생각할지도 모르지만 그게 아니라 웹브라우저 프로그램 그 자체에 공개키를 알린다는 것이다.

📍 사용자가 사이트랑 사용하는 방식은?

이렇게 웹브라우저가 공개키를 알고 있고, 사이트가 인증서를 가지고 있다면 여기서 사용자는 공개키를 아는 웹브라우저를 사용해 사이트에 접근한다. 그럼 사이트는 발급받았던 인증서를 전송하고, 이를 받은 웹브라우저는 공개키를 가지고 복호화해 사이트 정보와 서버의 공개키를 알게 된다. 이렇게 얻은 서버의 공개키로 대칭키를 암호화하여 다시 사이트에게 보낸다. 그럼 사이트는 개인키로 이를 복호화해 대칭키를 얻고 그 다음부터는 서로 대칭키만을 가지고 정보를 주고 받는다. 그리고 세션이 종료되면 대칭키를 폐기한다.

📍 그럼 오로지 보안 때문에 사용하나?

물론 가장 큰 사용 이유는 물론 보안이다. 정말 중요한 부분이기도 하고.. 하지만 요즘 사이트들 사이에서 필수적인 이유를 하나 더 들자면 SEO, Search Engine Optimization 즉, 검색 엔진 최적화 때문이기도 하다. 네이버 구글 등의 검색 엔진 사이트에서는 신뢰할 수 있는 사이트들을 우선 순위로 상위에 노출시키는 데 이 때 판단 기준으로 보안이 들어가기 때문이다. 노출도가 중요한 웹사이트에게 있어 당연히 중요하게 여겨질 수 밖에 없다. 그렇기 때문에 요즘에는 보통 다 적용하는 추세다. 하지만 HTTPS가 하는 암호화가 과부화를 주어 속도를 늦추는 등 단점도 있기 때문에 사이트의 일부만을 HTTPS로 관리하고 그렇지 않는 사이트는 HTTP를 사용하기도 한다.

➕ 공부자료

[네트워크] HTTPS (개념, SSL/TLS 암호화 과정, 장단점)

최근 진행한 프로젝트에서 음성인식 때문에 Webkit 기반의 Speech Recognition API를 사용했다. 로컬 환경에서는 카메라 및 마이크 요청을 허용해주니 문제 없이 잘 됐지만, AWS에 배포한 후 실제 웹 환경

eun-jeong.tistory.com

저작자표시 (새창열림)

'Computer Science > Web' 카테고리의 다른 글

HTTP 웹 지식 - URI와 웹 브라우저 요청 흐름 (0)	2023.03.06
HTTP 웹 지식 - 인터넷 네트워크 (0)	2023.03.06
XML (0)	2022.12.28
OAuth 2.0 (2)	2022.12.15
인증 / 인가 / 쿠키-세션 인증 / JWT 인증 간단개념 (0)	2022.12.03

XML ( eXtensible Markup Language )

정의

HTML과 매우 비슷한 문자 기반의 마크업 언어(text-based markup language)이며 데이터를 설명하는 태그(tag)를 사용자 마음대로 정의할 수 있는 확정성 있는 마크업 언어이다.

저장되는 데이터의 구조를 기술하기 위한 언어로 사람과 기계가 동시에 읽기 편한 구조로 구성되어 있다.

<cats>
    <cat>
        <name>루루</name>
        <family>먼치킨<family>
        <age>5</age>
        <weight>2.7</weight>
    </cat>
    <cat>
        <name>야통이</name>
        <family>코리안숏헤어<family>
        <age>4</age>
        <weight>5</weight>
    </cat>
</cats>

XML문서는 HTML문서처럼 트리(tree) 형태의 계층 구조를 갖는다.

문서당 하나뿐인 루트에서 시작하여 자식 요소에 연결되며 모든 요소는 자신만의 자식 요소를 가질 수 있다.

부모 요소는 여러 개의 자식 요소를 가질 수 있으나 자식 요소에게 부모는 하나 뿐이다.

같은 부모에서 뻗어져 나와 같은 트리 레벨에 존재하면 형제 요소라고 한다.

HTML과 뭐가 다를까?

- HTML이 Data를 "표현"하는데 포커스를 맞추고 있다면 XML은 Data를 "전달"하는데 포커스를 맞추고 있다.

- HTML은 약속된 태그를 사용하지만 XML은 tag가 정의 되어 있지 않아 확장성이 좋다.

그외의 XML 특징들

- XML은 데이터를 텍스트 형식으로 저장하여, 소프트웨어나 하드웨어에 독립적으로 데이터를 저장, 전달 가능하다.

- 텍스트 형식이기 때문에 운영체제, 프로그램, 브라우저 할 것 없이 모두에게 데이터 전달이 가능하다.

- XML은 데이터를 보여주지 않고, 오로지 데이터를 전달, 저장하는 것만을 목적으로 한다.

데이터를 보낼 때 사용하는 수단?

XML도 나름 HTML등의 언어를 극복하는 수단으로서 등장했으나 헤더와 태그등의 여러 요소들로 인해 가독성이 떨어지고 용량도 효율적이지 않다는 평가를 받게되어 이 문제점을 해결하고 보완하는 것이 나오게 된다.

그게 무엇일까?

현재의 우리가 프로젝트를 하면서 데이터를 보낼 때 사용하는 수단으로 무엇을 이용하고 있는가를 생각해보면 답이 나온다.

맞다. JSON을 이용하고 있다.

JSON은 XML과 뭐가 다를까?

- JSON은 종료 태그가 없다

- JSON의 구문이 XML 구문보다 짧다

- JSON 데이터가 XML 데이터보다 더 빨리 읽고 쓸 수 있다.

XML 문서는 XML DOM이라는 Document Object Model을 이용해 해당 문서에 접근하지만 JSON은 문자열을 전송 받은 후 해당 문자열을 바로 파싱하므로, XML보다 속도 처리가 빠르다.

- XML은 배열을 사용할 수 없지만, JSON은 배열을 사용할 수 있다.

{
    "name": "야통이",
    "family": "코리안숏헤어",
    "age": 4,
    "weight": 5
}

그럼 이제 XML 안 쓰나?

그렇지 않다. JSON은 전송받은 데이터의 무결성을 사용자가 직접 검증해야 한다.

그래서 경우에 따라 데이터의 무결성을 검증을 미리 정해놔야할 필요가 있는 경우가 있는데 이때 스키마를 사용해 무결성을 검증할 수 있는 XML을 많이 사용하고 있고 아직도 W3C (World Wide Web Consortium) 에서의 권고안으로 XML이 정해져있기에 다양하게 사용되고 있고, 이를 기반으로 한 또 다른 기술들도 많다.

XHTML, MathML, SVG, XUL, RDF 등

RSS ( Rich Site Summary ) : 블로그처럼 컨텐츠 업데이트가 자주 일어나는 웹사이트에서 업데이트 정보를 쉽게 구독자에게 제공하기 위해 XML을 기초로 만들어진 데이터 형식

저작자표시 (새창열림)

'Computer Science > Web' 카테고리의 다른 글

HTTP 웹 지식 - URI와 웹 브라우저 요청 흐름 (0)	2023.03.06
HTTP 웹 지식 - 인터넷 네트워크 (0)	2023.03.06
HTTPS (0)	2023.01.14
OAuth 2.0 (2)	2022.12.15
인증 / 인가 / 쿠키-세션 인증 / JWT 인증 간단개념 (0)	2022.12.03