기록하는 개발자

웹 개발자라면 한 번쯤은 CORS(Cross - Origin - Resource - Sharing) 정책 이슈를 경험해 봤을 것입니다. 저 또한 대학생 시절에 했던 토이 프로젝트에서 CORS 이슈를 경험했고, 처음 맞닥뜨렸을 때는 무엇이 문제인지 알기가 어려웠던 기억이 있습니다. CORS는 Cross-Origin Resource Sharing의 줄임말로, 교차 출처 리소스 공유라고 해석할 수 있습니다. 교차 출처 리소스 공유... 개인적으로 말이 너무 어렵다고 생각합니다. '교차 출처(Cross-Origin)' 라고 하는 것은 쉽게 말하면 '다른 출처'라고 생각하면 좀 더 쉽게 이해할 수 있을 것 같습니다. 먼저, 출처가 무엇인지 알아보겠습니다. Origin 서버의 위치를 의미하는 URL은 여러 구성 요..

TCP/IP를 공부하던 중 TCP는 데이터 송수신의 순서를 보장한다는 글을 읽었다. 학교에서 네트워크 수업을 들을 때 분명히 패킷이 분할되고 재조립하는 과정을 거친다고 했었다. 송신측에서 전달한 데이터는 패킷으로 분할되고, 패킷은 라우터를 거치며 수신측으로 보내지기 때문에 수신측에 패킷이 도착하는 순서가 보장되지 않는다는 생각이 문득 들었다. 패킷이 수신측에 순서대로 도착하지 않는데 TCP는 왜 순서를 보장하지? 라는 의문이 생겨서 관련 내용을 쭉 찾아봤는데, 추상적으로 설명해놓은 글이 많아 정리하려고 한다. TCP/IP 네트워크 통신을 위한 과정을 분류하는 모델로 OSI 7 계층이라는 표준이 존재한다. 우리가 HTTP 통신을 하기 위해 주로 사용하는 TCP/IP 프로토콜을 OSI 7 계층에 맞추어 추상..

데이터 송신 수신 동작의 개요 DNS 서버를 통해 IP 주소를 조사했으면 액세스 대상 웹 서버에 메시지를 송신하도록 OS 내부에 있는 프로토콜 스택에 의뢰한다. 디지털 데이터를 송, 수신 하는 동작은 브라우저뿐만 아니라 네트워크를 이용하는 애플리케이션 전체에 공통이므로 이 동작은 웹에 한정되지 않고 모든 네트워크 애플리케이션에 해당된다. 여기에서도 DNS 서버에 IP 주소를 조회할 때와 같이 Socket 라이브러리에 들어있는 메서드들을 이용하는데, IP 주소를 조회할 때 처럼 하나씩 호출하고 끝나지는 않는다. 많은 메서드들을 결정된 순번대로 호출해야 하므로 복잡한 과정을 거친다. 즉, OS 내부의 프로토콜 스택에 메시지 송신을 의뢰할 때는 Socket 라이브러리 프로그램 메서드를 결정된 순서대로 호출한다..

DNS 서버의 기본 동작 DNS 서버의 기본 동작은 클라이언트에서 조회 메시지를 받고 조회 내용에 응답하는 형태로 정보를 응답하는 일이다. 클라이언트의 조회 메시지에는 다음의 세 가지 정보가 포함된다. 1. 이름 서버나 메일 전송 목적지와 같은 이름이다. gray1234@google.com이라고 하면 google.com을 의미한다. 2. 클래스 클래스는 항상 인터넷을 나타내는 'IN' 값을 사용한다. 3. 타입 이름에 어떤 타입의 정보가 지원되는지 나타낸다. 예를 들어 타입이 A(주소)이면 이름에 IP 주소가 지원되는 것을 나타낸다. 예를 들어 이름이 www.lab.google.com인 서버의 IP 주소를 조사할 때 클라이언트는 이름 = www.lab.google.com , 클래스 = IN, 타입 = A..

IP 주소의 기본 HTTP 메시지를 만들면 이후에는 OS에 의뢰하여 액세스 대상의 웹 서버에게 송신한다. 앞서 설명한 것처럼 브라우저는 URL을 읽고 HTTP 메시지를 만들지만, 메시지를 네트워크에 송출하는 기능은 없으므로 운영체제에 네트워크에 송출하도록 위임한다. 이때 URL안에 쓰여있는 서버의 도메인 명에서 IP 주소를 획득해야 한다. IP 주소는 TCP/IP의 개념에 기초해서 만들어졌고, TCP/IP는 서브넷이라는 작은 네트워크를 라우터로 접속하여 전체 네트워크가 만들어진다고 생각할 수 있다. 쉽게 생각하면 하나의 허브에 여러 컴퓨터가 접속되었다는 것이다. IP 주소는 OO동 OO번지 라는 형태로 네트워크 주소를 할당받는데, 여기서 동에 해당하는 번호가 서브넷에 할당되고, 번지에 해당하는 호스트 번..

1. 웹 브라우저 여행은 URL 입력부터 시작한다 URL은 http 뿐만 아니라 ftp, file, mailto로 시작하는 것 등 여러 가지가 있다. 웹 서버에 접근할 때는 http, FTP 서버에 접근할 때는 ftp 라는 식으로 여러 종류의 URL이 준비되어 있다. 모든 URL에는 공통점이 있는데, 맨 앞에 있는 문자열에서 엑세스하는 방법을 나타낸다는 것이다. * HTTP 프로토콜로 웹 서버에 엑세스하는 경우 http://user:password@www.cyber.co.kr:80/dir/file1.htm * FTP 프로토콜로 파일을 다운로드하거나 업로드하는 경우 ftp://user:password@ftp.cyber.co.kr:21/dir/file1.htm * 클라이언트 PC 자체의 파일에서 데이터를 읽..

클라이언트와 서버간의 통신에서 HTTP 통신을 사용할 때 request, response를 사용한다. HTTP 요청 메시지를 통해 클라이언트에서 서버로 데이터를 전달하는 방법은 3가지가 있다. 1. GET - 쿼리 파라미터 2. POST - HTML FORM 3. HTTP API message Body GET - 쿼리 파라미터 먼저 GET 쿼리 파라미터를 이용한 방식부터 알아보자. "/url?username=kim&age=20" 처럼 메시지 바디 없이 URL의 쿼리 파라미터에 데이터를 포함해서 전달한다. 검색, 필터, 페이징등에서 많이 사용하는 방식이다. 쿼리 파라미터는 ?를 시작으로 보낼 수 있고 추가 파라미터는 &로 구분하면 된다. 자바코드를 이용해 쿼리 파라미터를 조회하는 과정을 살펴보면 Strin..

캐시가 없는 경우 서버에 요청이 들어오면 서버에서 헤더와 바디를 만들어 내려준다 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운 받아야 한다 인터넷 네트워크는 매우 느리고 비싸고, 브라우저 로딩 속도가 느려진다 캐시를 적용하는 경우 브라우저 캐시에 일정 시간동안 저장한 후 다음 접근은 캐시에서 조회하여 요청을 받아온다 -> 네트워크를 사용하지 않음 만약 일정 시간이 초과된 경우 다시 서버로 요청을 보내 응답 받음 -> 캐시를 갱신한다 -> 네트워크 사용 • 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다. • 비싼 네트워크 사용량을 줄일 수 있다. • 브라우저 로딩 속도가 매우 빠르다. • 빠른 사용자 경험 캐시 시간 초과 캐시 유효 시간이 초과해서 서버에 다시 요청하면 다..

HTTP 헤더 개요 • 메시지 본문(message body)을 ,통해 표현 데이터 전달 • 메시지 본분 = 페이로드(payload) • 표현은 요청이나 응답에서 전달할 실제 데이터 • 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공 • 데이터 유형(html, json), 데이터 길이, 압축 정보 등등 표현 어떤 리소스를 html이라는 표현으로 전달할 것이냐, json형태의 표현으로 전달할 것이냐 • Content-Type: 표현 데이터의 형식 설명 - 미디어 타입, 문자 인코딩 - 예) text/html; charset=uft-8 • Content-Encoding: 표현 데이터 인코딩 - 표현 데이터를 압축하기 위해 사용 - 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가 - 데이터를 읽는 쪽에..

상태 코드 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능 1xx (Informational): 요청이 수신되어 처리 중 2xx (Successful): 요청 정상 처리 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함 만약 모르는 상태 코드가 나타나면 백의 자리 숫자를 보고 판단하면 된다 1xx (Informational): 요청이 수신되어 처리 중 • 거의 사용하지 않음 2xx (Successful): 요청 정상 처리 • 200 OK: 요청 성공 • 201 Created: 요청 성공해서 ..