Java

HTTP 사전 기반 기초 지식

ryeonng 2024. 7. 2. 12:34

1. 인코딩과 포트

언어에서의 약속

문장의 의미는 문장을 구성하는 단어의 의미, 문법 구조, 맥락, 독자의 배경 지식 등으로 결정된다.이 중 단어의 의미와 문법은 사회적으로 합의되어 있다.

 

인코딩

컴퓨터의 모든 데이터는 0과 1로 구성된다. 지금 보고 있는 글도 사실은 0과 1의 집합이다. “사과”가 사과를 가리키는 데 약속이 필요하듯, 0과 1로 우리의 문자를 표현하는 것도 일종의 약속 덕분이다. 이런 약속들을 특별히 인코딩(Encoding) 표준이라고 부르는데, 대표적으로 아스키(Ascii)와 유니코드(Unicode)가 있다.

 

아스키는 7비트 데이터에 대한 인코딩 표준이다. 이를 이용하면 알파벳과 특수 문자 등을 표현할 수 있다. 예를 들어, 아스키에서 1 한 개, 0 다섯 개, 1 한 개를 이어 붙이면 “A”로 해석된다. 이에 따라 “1000001”이라는 데이터를 아스키로 변환하면 “A”가 된다.

 

컴퓨터가 개발된 초기에는 각 문자권마다 고유의 인코딩 표준을 사용했다. 영어는 아스키, 한글은 CP-949, EUC-KR 등을 사용했다. 그런데 이러한 방식은 호환성 측면에서, 국제 소프트웨어를 개발하려는 회사에 큰 부담이 됐다. 가끔 소프트웨어를 실행했을 때 글자가 🆡🆡🆡 등으로 출력되는 것이 인코딩이 호환되지 않아 발생하는 문제이다.

 

이러한 어려움을 해결하고자 유니코드라는 새로운 표준이 만들어졌다. “Uni(하나의)”라는 접두사가 나타내듯, 유니코드는 모든 언어의 문자를 하나의 표준에 담겠다는 목표로 제정되었다. 유니코드에서 한 문자는 최대 32개의 비트로 표현된다. 32비트로 표현할 수 있는 정보의 가짓수는 2^{32}2 32, 대략 42억 개이다. 전 세계의 문자를 표현하고도 남을 넓은 공간이다. 그래서 최근에는 한글, 한자, 히라가나, 가타카나, 알파벳과 같은 문자 외에 각종 이모지(Emoji)들도 유니코드에 포함되고 있다. 😁

 

인코딩을 이용하면 우리의 문장을 컴퓨터에 저장하고, 표현할 수 있다. 그리고 네트워크를 이용하면 인코딩한 정보를 다른 사람들과 쉽게 교환할 수도 있다.

 

 

네트워크 포트와 서비스 포트

네트워크 포트(Network Port)란 네트워크에서 서버와 클라이언트가 정보를 교환하는 추상화된 장소를 의미한다. 포트에는 항구라는 의미가 있는데, 클라이언트가 서버의 포트에 접근하여 데이터를 내려놓고, 서버가 클라이언트에 보낼 데이터를 실어서 돌려보내는 장면을 연상하면 포트의 기능을 이해할 수 있다. 편의상, 네트워크를 설명하는 맥락에서는 네트워크를 생략하여 “포트”라고 부르기도 한다.

 

서비스 포트(Service Port)는 네트워크 포트 중에서 특정 서비스가 점유하고 있는 포트를 이른다. 예를 들어, HTTP가 80번 포트를 점유하고 있다면 HTTP의 서비스 포트는 80번 포트가 된다.

 

포트로 데이터를 교환하는 방식은 전송 계층(Transport Layer)의 프로토콜을 따른다. 대표적으로는 TCP와 UDP가 있다. TCP로 데이터를 전송하려는 서비스에 UDP 클라이언트가 접근하면, 데이터가 교환되지 않는다. 반대의 경우도 마찬가지다. 그래서 서비스 포트를 표기할 때는 서비스가 사용하는 전송 계층 프로토콜을 같이 표기하기도 한다. 예를 들어, HTTP의 서비스 포트가 TCP/80 이라고 하면, HTTP 서비스를 80번 포트에서 TCP로 제공하고 있다는 뜻이다.

 

포트의 개수는 운영체제에서 정의하기 나름이다. 그러나 현대의 윈도우나 리눅스, 맥 운영체제는 0번 부터 65535번까지, 총 65536개의 같은 수의 네트워크 포트를 사용한다.

 

포트 중 0번부터 1023번 포트는 잘 알려진 포트(Well-known port) 또는 특권 포트(Privileged port)라고 한다. 문자 그대로 각 포트 번호에 유명한 서비스가 등록되어 있다. 대표적으로 22번 포트에는 SSH, 80에는 HTTP, 443에는 HTTPS가 할당되어 있다. 잘 알려진 포트에 서비스를 실행하려면 관리자 권한이 필요하다. 따라서 클라이언트는 이 대역에서 실행 중인 서비스들은 관리자의 것이라고 신뢰할 수 있다.

 

 

2. 통신 프로토콜

웹 서버에 있는 리소스를 클라이언트가 받아 보려면, 클라이언트는 웹에게 특정 리소스를 지정하여 제공해달라고 요청해야 한다. 그러면 서버가 해당 요청을 이해하고, 대응되는 동작을 통해 클라이언트에게 리소스를 반환한다. 여기서 클라이언트의 행위를 요청(Request), 서버의 행위를 응답(Response)이라고 한다.

 

요청과 응답은 우리의 일상에서도 빈번히 일어나는 상호작용이다. 집에서, 가게에서, 회사에서 누군가에게 뭔가를 달라고 할 때는 항상 요청과 응답이 이뤄진다. 눈여겨볼 점은 이러한 행위가 어느 정도 약속되어 있다는 것이다. A에게 B를 요구할 때, “A야 B 좀 줘”라고 이야기하면, A가 B를 찾아서 건네준다. 상황에 따라 요청의 뉘앙스가 조금 바뀔 수는 있지만, 대개는 비슷하다.

 

프로토콜(Protocol)은 위와 같이 규격화된 상호작용에 적용되는 약속을 이른다. 일상생활의 상호작용은 대부분 관습 또는 에티켓이라는 형태의 느슨한 프로토콜을 따른다. 통화할 때는 보통 “여보세요”로 시작해서 본론을 말하고 “끊어”, “바이” 등으로 통화를 끝맺는다. 그런데 때에 따라서는 본론을 말하기 전에 서로 신원을 밝히거나, 아예 인사를 생략할 수 있다. 맥락을 아는 사람만 이해할 수 있는 애매한 표현을 사용할 수도 있다. 이처럼 일상에서 사람과 사람이 통신할 때는 관습을 따르되, 약간의 융통성을 발휘해도 정보를 교환하는 데 큰 문제가 발생하지 않는다.

 

반면, 컴퓨터와 통신할 때는 비교적 엄격한 프로토콜을 사용해야 한다. 왜냐하면, 컴퓨터가 해석의 융통성을 발휘하게 하는 것은 매우 어렵고, 이 과정에서 오히려 통신 오류가 발생할 가능성을 높일 수 있기 때문이다. 그래서 많은 컴퓨터 통신 프로토콜은 각 통신 주체가 교환하는 데이터(이하 메시지)를 명확히 해석할 수 있도록 문법(syntax)을 포함한다. 일반적으로 이 문법에 어긋나는 메시지는 잘못 전송된 것으로 취급하여 무시된다. 예를 들어, 웹 서버에 “GET A”라고 보낼 것을 “GIVEME A”라고 보내면, “GET”과 “GIVEME”의 의미가 비슷하므로 A를 반환할 만하지만, 웹서버에서는 이를 오류로 처리한다.

 

현재까지 제정된 표준 통신 프로토콜에는 네트워크 통신의 기초가 되는 TCP/IP, 웹 애플리케이션이 사용하는 HTTP, 파일을 주고받을 때 사용하는 FTP 등 매우 많은 종류가 있다.

 

 

HTTP 통신은 Request 와 Response에 여행이다.

Http(Hyper Text Transfer Protocol)란 서버와 클라이언트의 데이터 교환을 요청(Request)과 응답(Response) 형식으로 정의한 프로토콜이다. 팀 버너스 리(Team Berners-Lee)와 그의 팀이 제정한 이후, 현대 웹 서비스의 바탕이 되는 프로토콜로 자리 잡았다.

 

Http의 기본 메커니즘은 클라이언트가 서버에게 요청하면, 서버가 응답하는 것이다. 웹 서버는 HTTP 서버를 HTTP 서비스 포트에 대기시킨다. 이 포트는 일반적으로 TCP/80 또는 TCP/8080이다. 클라이언트가 서비스 포트에 HTTP 요청을 전송하면, 이를 해석해 적절한 응답을 반환한다. 

 

오른쪽 탭에 요청과 응답의 예시가 있다. 데이터 위에 마우스를 올리면, 각 필드에 대한 설명을 확인할 수 있다.

 

● HTTP 통신을 요청할 때, HTTP 메시지를 만들어서 보낸다.(Request)

 

 

3. HTTP 메시지

HTTP 메시지에는 클라이언트가 전송하는 HTTP 요청, 그리고 서버가 반환하는 HTTP 응답이 있다. 기능과 세부 구조에서는 차이가 있지만, 크게 보면 이들은 HTTP 헤드와 바디로 구성된다는 공통점이 있다. 

 

· HTTP 헤드

HTTP 헤드의 각 줄은 CRLF로 구분되며, 첫 줄은 시작 줄(Start-line), 나머지 줄은(Header)라고 부른다. 헤드의 끝은 CRLF 한 줄로 나타낸다.

· HTTP 바디

HTTP 바디는 헤드의 끝을 나타내는 CRLF 뒤, 모든 줄을 말한다. 클라이언트나 서버에게 전송하려는 데이터가 바디에 담긴다.

 

 

4. HTTP 요청

HTTP 요청은 서버에게 특정 동작을 요구하는 메시지이다. 서버는 해당 동작이 실현 가능한지, 클라이언트가 그러한 동작을 요청할 권한이 있는지 등을 검토 후, 적절할 때에만 이것을 처리한다.

 

시작 줄

HTTP 요청의 시작 줄은 메소드(Method), 요청 URI(Request-URI), 그리고 HTTP 버전으로 구성됩니다. 각각은 띄어쓰기로 구분한다.

 

· 메소드

URI가 가리키는 리소스를 대상으로, 서버가 수행하길 바라는 동작을 나타낸다. HTTP 표준에 정의된 메소드는 8개가 있으나, 여기서는 비교적 자주 사용되는 GET과 POST 메소드만 설명할 것 이다.

GET은 리소스를 가져오라는 메소드이다. 이용자가 브라우저에 웹 서버의 주소를 입력하거나 하이퍼링크를 클릭하면, 새로운 페이지를 렌더링하기 위해 리소스가 필요하다. 이때 브라우저는 GET 요청을 서버에 전송하여 리소스를 받아온다.

POST는 리소스로 데이터를 보낸다는 메소드이다. 전송할 데이터는 보통 HTTP 바디에 포함된다. 로그인할 때 입력하는 ID와 비밀번호, 게시판에 작성하는 글 등이 POST로 서버에 보내진다. 이 외에 요청 URI는 메소드의 대상을, HTTP 버전은 클라이언트가 사용하는 HTTP 프로토콜의 버전을 나타낸다.

 

· GET 방식의 요청 HTTP 메시지 모양

· POST 방식의 요청 HTTP 메시지 모양

 

 

 

5. HTTP 응답

HTTP 응답은 HTTP 요청에 대한 결과를 반환하는 메시지이다. 요청을 수행했는지, 하지 않았는지, 안 했다면 이유는 무엇인지와 같은 상태 정보(Status), 그리고 클라이언트에게 전송할 리소스가 응답에 포함된다.

 

시작 줄

HTTP 응답의 시작 줄은 HTTP 버전, 상태 코드(Status Code), 그리고 처리 사유(Reason Phrase)로 구성되며, 각각은 띄어쓰기로 구분된다.

 

HTTP 버전은 서버에서 사용하는 HTTP 프로토콜의 버전을 나타낸다. 그리고 상태 코드는 요청에 대한 처리 결과를 세 자릿수로 나타낸다. HTTP 표준인 RFC 2616은 대략 40여개의 상태 코드를 정의하고 있는데, 각각은 첫 번째 자릿수에 따라 5개의 클래스로 분류된다. 처리 사유는 상태 코드가 발생한 이유를 짧게 기술한 것이다.

 

상태 코드

1xx
요청을 제대로 받았고, 처리가 진행 중임

2xx
요청이 제대로 처리됨
200: 성공

3xx
요청을 처리하려면, 클라이언트가 추가 동작을 취해야 함.
302: 다른 URL로 갈 것

4xx
클라이언트가 잘못된 요청을 보내어 처리에 실패했습니다.
400: 요청이 문법에 맞지 않음
403: 클라이언트가 리소스에 요청할 권한이 없음
404: 리소스가 없음

5xx
클라이언트의 요청은 유효하지만, 서버에 에러가 발생하여 처리에 실패했습니다.
500: 요청을 처리하다가 에러가 발생함
503: 서버가 과부하로 인해 요청을 처리할 수 없음

 

 

6. HTTPS 

HTTP의 응답과 요청은 평문으로 전달된다. 만약 누군가 이를 가로챈다면 중요한 정보가 유출될 수 있다. 예를 들어, 로그인할 때 전송한 POST 요청에는 대개 이용자의 ID와 비밀번호가 포함된다. 공격자가 중간에 이를 가로채면 이용자의 계정이 탈취당할 수 있다.

 

HTTPS(HTTP over Secure socket layer)는 TLS(Transport Layer Security) 프로토콜을 도입하여 이런 문제점을 보완한다. TLS는 서버와 클라이언트 사이에 오가는 모든 HTTP 메시지를 암호화한다. 공격자가 중간에 메시지를 탈취하더라도 이를 해석하는 것은 불가능하며, 결과적으로 HTTP 통신이 도청과 변조로부터 보호된다.

 

HTTPS가 제정된 초기에는 금융이나 정부 서비스와 같이 민감한 데이터를 취급하는 웹 서비스들 위주로 HTTPS가 사용되었다. 그러나 현재 개발되는 서비스들은 규모에 상관없이 HTTPS를 사용하는 추세이다.

 

웹 서버의 URL이 http://로 시작되면 HTTP, https://로 시작되면 HTTPS 프로토콜을 사용한다.

 

정리

HTTP(HyperText Transfer Protocol) : 웹 서버와 클라이언트가 리소스를 교환하기 위해 사용하는 프로토콜. 클라이언트가 요청하면, 서버가 응답하는 방식.

 

HTTP 메시지 : HTTP 서버와 클라이언트가 교환하는 데이터. 헤드와 바디로 구성되며, 각 줄은 CRLF로 구분 됨.

헤드 : 메시지에 대한 정보. 헤드의 끝에는 CRLF가 한 줄 있다.

바디 : 클라이언트가 서버에게, 또는 서버가 클라이언트에게 전달할 데이터

 

HTTP 요청(Request) : 클라이언트가 서버에게 특정 동작을 요청하는 메시지

메소드(Method) : 요청 URI가 가리키는 리소스에 대해, 서버가 수행했으면 하는 동작을 지정

요청 URI(Request-URI) : 메소드의 대상이 되는 리소스를 지정

HTTP 응답(Response) : 요청을 처리한 결과 및 이유, 그리고 클라이언트에 전송할 웹 리소스를 포함하는 메시지

 

상태 코드(Status Code) : 요청을 처리한 결과

처리 사유(Reason Phrase) : 상태 코드가 발생한 이유

HTTPS(HTTP on Secure socket layer) : TLS를 이용하여 HTTP의 약점을 보완한 프로토콜

 

 

7. Web

 

인터넷을 기반으로 구현된 서비스 중 HTTP를 이용하여 정보를 공유하는 서비스를 웹이라고 한다. 

여기서 정보를 제공하는 주체를 웹 서버 (Web Server), 정보를 받는 이용자를 웹 클라이언트 (Web Client) 라고 한다.

 

식당에서 음식을 서빙하는 사람 (Server)과 음식을 주문하는 고객 (Client)의 관계로 생각하면 된다. 여기서, HTTP란 웹상에서 서로 통신을 하기 위해 정해둔 일종의 규칙이다.

 

웹의 발전과 웹 보안의 중요성

초기 웹 서비스는 저장된 문서의 내용을 출력해 이용자에게 제공하는 간단한 서비스 였다. 그런데 웹과 관련된 기술이 발전하면서 이제는 금융, 쇼핑, 협업 등 다양한 분야에서 이용자에게 편의를 주는 복잡한 서비스로 진화했다. 과거에는 단순히 정보를 보여주는 것에서 그쳤다면, 현재는 정보를 검색하고 직접 제품을 구매할 수 있도록 변화하였다.이러한 웹의 발전은 우리의 일상을 많은 부분에서 바꿔놓았으며, 오프라인에서 이뤄지던 많은 상호작용이 현재는 디지털 형태로 변환되어 웹 서비스로 구현되고 있다.

 

한편, 웹에서 처리하는 정보 자산들이 많아짐에 따라 이들을 안전하게 보관하고 처리해야 할 필요성도 함께 증가하였다. 예를 들어, 고객이 물건을 구매하는 과정에서는 고객의 주소, 카드 번호 등의 정보들이 웹을 통해 서버로 전달된다. 만약 이 정보들이 안전하게 보호되지 않는다면 고객에게 심각한 피해를 야기할 수 있다. 그래서 웹을 통한 정보의 교환 과정에서 이러한 민감한 정보들이 유출되거나 악용되지 않도록 보호하는 웹 보안의 중요성이 대두하고 있다.

 

웹 서비스, 프론트엔드와 백엔드

앞서 말한 것과 같이 웹 서비스는 다양한 기능을 수행하는 형태로 발전했다. 이전의 웹 서비스가 이용자가 요청하는 정보를 제공하기만 하는 수동적인 형태의 서비스였다면, 현재는 이용자의 요청을 해석하고 가공하여 필요한 정보와 기능을 제공하는 능동형 서비스에 가깝다. 예를 들어, 구글과 같은 검색 서비스는 이용자가 “검색어”라는 형태로 자신이 원하는 정보를 추상화해서 전달하면, 구글이 이를 해석하고 가공하여 필요한 정보를 제시한다.

 

이런 서비스 구조에서, 이용자의 요청을 받는 부분을 프론트엔드 (Front-end), 요청을 처리하는 부분을 백엔드 (Back-end)라고 부른다. 호텔 프론트에 이런저런 서비스를 요청하면 뒤의 공간에서 고객 모르게 복잡한 일들이 벌어지는 것과 비슷하다.

 

프론트엔드는 이용자에게 직접 보여지는 부분으로, 웹 리소스 (Web Resource)라는 것으로 구성된다. 페이지가 보여주고 있는 정보들은 모두 웹 리소스에 명시되어 있다. 페이지에 담기는 글, 글자들의 색깔과 모양, 배경 색상, 이미지의 크기나 투명도 등이 관련 언어로 적혀있다.

 

8. 웹 리소스

웹 리소스란, 웹에 갖춰진 정보 자산을 의미한다.

 

웹 브라우저의 주소창에  https://www.naver.com/index.html 주소를 입력하면 naver.com 에 존재하는 /index.html 경로의 리소스를 가져오라는 의미이다. 모든 웹 리소스는 고유의 Uniform Resouce Indicator (URI)를 가지며, 이를 이용하여 식별된다.

 

웹의 프론트엔드를 구성하는 대표적인 웹 리소스들은 다음과 같다.

 

Hyper Text Markup Language (HTML)

웹 문서의 뼈와 살을 담당한다. 태그와 속성을 통한 구조화된 문서 작성을 지원한다.

 

Cascading Style Sheets (CSS)

웹 문서의 생김새를 지정한다. 웹 리소스들의 시각화 방법을 기재한 스타일 시트이다. 글자의 색이나 모양, 배경 색, 이미지 크기나 위치 등을 CSS로 지정할 수 있다. 브라우저는 이를 참고하여 웹 문서를 시각화한다.

 

JavaScript (JS)

웹 문서의 동작을 정의한다. 이용자가 버튼을 클릭했을 때, 어떻게 반응할지, 이용자가 데이터를 입력하면 어디로 전송할지 등을 JS로 구현할 수 있다. JS는 이용자의 브라우저에서 실행되는데, 클라이언트가 실행하는 코드라고 하여 Client-Side Script라고도 부른다.

 

그 외

문서, 이미지, 동영상, 폰트 등이 있다.

 

9. 웹 클라이언트와 서버의 통신

웹 서비스의 통신 과정을 간략화하면 다음과 같다.

 

(클라이언트) 이용자가 브라우저를 이용해 웹 서버에 접속한다.

(클라이언트) 브라우저는 이용자의 요청을 해석해 HTTP 형식으로 웹 서버에 리소스를 요청한다.

(서버) HTTP로 전달된 이용자의 요청을 해석한다.

(서버) 해석한 이용자의 요청에 따라 적절한 동작을 한다.

리소스를 요청하는 것이라면, 이를 탐색한다.

계좌 송금, 입금과 같은 복잡한 동작을 요구할 경우 내부적으로 필요한 연산을 처리한다.

(서버) 이용자에게 전달할 리소스를 HTTP 형식으로 이용자에게 전달한다.

(클라이언트) 브라우저는 서버에게 응답받은 HTML, CSS, JS 등의 웹 리소스를 시각화하여 이용자에게 보여준다.

 

용어 정리

통신 - 정보를 전하는 것. 현대에는 전화, 인터넷 등의 통신 수단을 이용해 과거보다 시간과 공간의 제약을 받지 않고 이뤄짐.

웹 - 인터넷이라는 통신망을 활용하여 구현된 전 지구적 정보 공간

웹 클라이언트 - 웹에서 정보를 요구하는 주체

웹 서버 - 웹에서 정보를 제공하는 주체

웹 리소스 - 웹 서버가 제공하는 정보 자원(e.g. HTML, Javascript, CSS 등)

웹 서비스 - 웹 상에서 제공되는 서비스 (e.g. SNS, 온라인 쇼핑몰 등)

 

10. 웹 브라우저

웹은 인터넷이라는 글로벌 네트워크 위에 구현되어 있으며, 정해진 프로토콜을 기반으로 통신한다. 개발자가 아닌 일반 이용자가 이러한 규칙을 이해하고 인터넷을 사용하기는 매우 어렵다. 만약 그랬다면 지금처럼 SNS와 커뮤니티가 활성화되지는 못했을 것이다. 20세기에 등장한 웹 브라우저는 서버와 HTTP 통신을 대신해주고, 수신한 리소스를 시각화하여 위와 같은 문제를 해결하였다.

 

웹 브라우저는 뛰어난 이용자 경험(User Experience, UX) 을 제공하는 소프트웨어 중 하나이다. 이용자는 브라우저를 이용하여 쉽게 정보를 검색하고, 동영상을 보고, 파일을 내려받지만 내부에서 어떠한 연산이 일어나는지는 전혀 알지 못한다.

 

브라우저를 통해 이용자가 주소창에 naver.com을 입력했을 때 웹 브라우저가 하게 되는 기본적인 동작을 나열한 것이다.

 

웹 브라우저의 주소창에 입력된 주소(naver.com)를 해석 (URL 분석)

naver.com에 해당하는 주소 탐색 (DNS 요청)

HTTP를 통해 naver.com 에 요청

naver.com의 HTTP 응답 수신

리소스 다운로드 및 웹 렌더링 (HTML, CSS, Javascript)

 

11. URL

URL은 Uniform Resource Locator의 약자로, 웹에 있는 리소스의 위치를 표현하는 문자열이다. 브라우저로 특정 웹 리소스에 접근할 때는, URL을 사용하여 이를 서버에게 요청한다. 다음은 URL의 예시이다.

 

URL은 Scheme, Authority (Userinfo, Host, Port), Path, Query, Fragment 등으로 구성된다. 이 중 자주 사용되는 요소는 다음과 같다.

: URL에 대한 더 자세한 정보는 RFC 3986에서 확인할 수 있다.

 

12. 웹 렌더링

웹 렌더링(Web Rendering)은 서버로부터 받은 리소스를 이용자에게 시각화하는 행위를 말한다.

 

서버의 응답을 받은 웹 브라우저는 리소스의 타입을 확인하고, 적절한 방식으로 이용자에게 전달한다. 예를 들어, 서버로부터 HTML과 CSS를 받으면 브라우저는 HTML을 파싱하고 CSS를 적용하여 이용자에게 보여준다.

 

웹 렌더링은 웹 렌더링 엔진에 의해서 이뤄지는데, 브라우저별로 서로 다른 엔진을 사용한다. 사파리는 웹킷(Webkit), 크롬은 블링크(Blink), 파이어폭스는 개코(Gecko) 엔진을 사용한다. 각각의 엔진에 따라 렌더링 과정과 순서, 속도의 차이는 있지만, HTML을 파싱하고 시각화하여 이용자에게 보여주는 것은 같다.

 

오른쪽 모듈은 HTML, CSS, JS로 구현된 간단한 웹 페이지이다. 이용자의 요청이 들어오면 서버는 웹 리소스들로 응답하고, 웹 브라우저는 이용자가 볼 수 있는 형태로 가공하여 화면에 출력한다.

 

키워드 정리

 

웹 브라우저(Web Browser)

웹 브라우저는 HTTP/S로 이용자와 웹 서버의 통신을 중개하며, 서버로부터 전달받은 다양한 웹 리소스들을 가공해 이용자에게 효과적으로 전달한다.

이용자가 다양한 프로토콜들을 알지 못해도 쉽게 웹을 사용할 수 있도록 도와준다.

 

URL(Uniform Resource Locator)

URL은 리소스의 위치를 나타내는 문자열로,

브라우저는 이를 사용하여 서버에 특정 리소스를 요청할 수 있습니다.

 

DNS(Domain Name Server)

Host의 도메인 이름을 IP로 변환하거나 IP를 도메인 이름으로 변환합니다.

 

웹 렌더링(Web Rendering)

서버로부터 받은 리소스를 이용자에게 시각화하는 것을 말합니다.

 

13. JSON

JSON (JavaScript Object Notation)

  • JavaScript Object Notation라는 의미의 축약어로 데이터를 저장하거나 전송할 때 많이 사용되는 경량의 DATA 교환 형식
  • Javascript에서 객체를 만들 때 사용하는 표현식을 의미한다.
  • JSON 표현식은 사람과 기계 모두 이해하기 쉬우며 용량이 작아서, 최근에는 JSON이 XML을 대체해서 데이터 전송 등에 많이 사용한다.
  • JSON은 데이터 포맷일 뿐이며 어떠한 통신 방법도, 프로그래밍 문법도 아닌 단순히 데이터를 표시하는 표현 방법일 뿐이다.

 

JSON 특징

  • 서버와 클라이언트 간의 교류에서 일반적으로 많이 사용된다.
  • 자바스크립트 객체 표기법과 아주 유사하다.
  • 자바스크립트를 이용하여 JSON 형식의 문서를 쉽게 자바스크립트 객체로 변환할 수 있는 이점이 있다.
  • JSON 문서 형식은 자바스크립트 객체의 형식을 기반으로 만들어졌다.
  • 자바스크립트의 문법과 굉장히 유사하지만 텍스트 형식일 뿐이다.
  • 다른 프로그래밍 언어를 이용해서도 쉽게 만들 수 있다.
  • 특정 언어에 종속되지 않으며, 대부분의 프로그래밍 언어에서 JSON 포맷의 데이터를 핸들링 할 수 있는 라이브러리를 제공한다.

 

XML vs JSON

데이터를 나타낼 수 있는 방식은 여러가지가 있지만, 대표적인 것이 XML이고, 이후 가장 많이 사용되는 것이 아마도 JSON일 것이다.

 

XML

데이터 값 양쪽으로 태그가 있다.

(HTML을 근본으로 했기에 태그라는 것이 없을 수가 없는데, 그 태그를 줄인다 해도 최소한 표현하려면 양쪽에 몇글자씩이 있어야 한다.)

 

JSON

태그로 표현하기 보다는 중괄호({}) 같은 형식으로 하고, 값을 ','로 나열하기에 그 표현이 간단하다.

 

JSON 문법

{
  "employees": [
    {
      "name": "Surim",
      "lastName": "Son"
    },
    {
      "name": "Someone",
      "lastName": "Huh"
    },
    {
      "name": "Someone else",
      "lastName": "Kim"
    } 
  ]
}
  • JSON 형식은 자바스크립트 객체와 마찬가지로 key / value가 존재할 수 있으며 key값이나 문자열은 항상 쌍따옴표를 이용하여 표기해야한다.
  • 객체, 배열 등의 표기를 사용할 수 있다.
  • 일반 자바스크립트의 객체처럼 원하는 만큼 중첩시켜서 사용할 수도 있다.
  • JSON형식에서는 null, number, string, array, object, boolean을 사용할 수 있다.

 

JSON의 문제점

AJAX 는 단순히 데이터만이 아니라 JavaScript 그 자체도 전달할 수 있다. 이 말은 JSON데이터라고 해서 받았는데 단순 데이터가 아니라 JavaScript가 될 수도 있고, 그게 실행 될 수 있다는 것이다. (데이터인 줄 알고 받았는데 악성 스크립트가 될 수 있다.)

 

위와 같은 이유로 받은 내용에서 순수하게 데이터만 추출하기 위한 JSON 관련 라이브러리를 따로 사용하기도 한다.

 

JSON 형식 텍스트를 JavaScript Object로 변환하기

var jsonText = '{ "name": "Someone else", "lastName": "Kim" }';  // JSON 형식의 문자열
var realObject = JSON.parse(jsonText);
var jsonText2 = JSON.stringify(realObject);

console.log(realObject);
console.log(jsonText2);
  • JSON.parse( JSON으로 변환할 문자열 ) : JSON 형식의 텍스트를 자바스크립트 객체로 변환한다.
  • JSON.stringify( JSON 문자열로 변환할 값 ) : 자바스크립트 객체를 JSON 텍스트로 변환한다.

'Java' 카테고리의 다른 글

WAS와 웹 컨테이너의 역할  (0) 2024.07.02
웹 서버와 웹 애플리케이션 서버(WAS)  (1) 2024.07.02
JDBC 성능 최적화  (0) 2024.06.27
JDBC를 활용한 CRUD 와 SOLID 원칙  (1) 2024.06.27
JDBC 트랜잭션 관리와 배치 처리  (0) 2024.06.27

'Java'의 다른글

  • 현재글HTTP 사전 기반 기초 지식

관련글

티스토리툴바