1시간 전•

11월 3일 학습일지

11월 3일

오늘 공부에 투자한 순수한 시간: 5시간

학습한 개념 : HTTP, URL

<HTTP>

1. HTTP는 HyperText Transfer Protocol의 약자이다. HyperText(하이퍼 텍스트)는 HTML에서 나온것처럼 링크가 서로 연결되어 있는 문서이다. 다음으로는 Transfer인데 이는 옮긴다 라는 뜻을 가지고 있으며 HTTP의 주 역할인 서버에서 브라우저로 연결하는 역할을 하는데 브라우저에서 서버에 요구하는 문서가 있으면 옮겨주는 역할을 한다. 마지막으로는 Protocol(프로트콜)인데 이는 원래 외교에서 사용되는 의례 혹은 공식 절차를 뜻하는 말이다. 이것이 컴퓨터에서는 통신을 할때 서로가 지키기로한 약속이 된다. 요청은 이런식으로 사용하고 응답은 이러한 형식으로 전달한다는 규칙, 약속 이라고 생각하면 된다. 폭 넓게 사용하면 단순 문서만 주고 받는것이 아닌 영상이나 이미지등를 연결해줄 수 있다.

ㄴ 그럼 protocol은 마크업을 사용하여 진행되는거야?

마크업과 프로트콜은 전혀 다른 방식으로 사용이 되는데 마크업은 단순히 HTML에서 사용되는 태그이며 프로트콜은 HTTP에서만 사용이되는데 프로트콜이 사용될때는 텍스트형식의 메시지만 사용이 된다. HTTP 즉 브라우저에서 서버 즉 HTML에게 요구하는데 이때는 단순히 텍스트 형태로만 메시지가 전달이 되며 서버 즉 HTML에서 처리할때는 마크업을 사용하여 처리를 해주는것이다. 그래서 우리가 인터넷에 검색을 할때 자언어로 질문하고 답할 수 있는 내용이 이 내용인것 같다.

2. 이 또한 팀 버너스리가 CERN에서 웹을 개발할때 함께 설계 하였으며 이후에 표준화 과정에서 로이 필딩과 헨릭 프리스틱 닐슨이 참여하였고, 또 IETF 참여자들이 함께 기여하였다. 처음 1989년에서 1990년까지는 웹에 대한 구상과 첫 서버, 브라우저를 만들게 되었으며 1991년 HTTP/0.9 가 완성이 되었는데 이는 'GIT/주소'만 넣으면 사용이 가능했으며 응답은 HTML의 문서만 받아볼 수 있는 수준이였다. 이후 1996년에는 HTTP/1.0 이 만들어 졌으며, 이때는 정보 문서와 헤더 즉 부가 정보까지 추가되면서, 이후에 상태창 200, 404 같은 오류의 상태도 확인할 수 있게 되었다. 이후에는 1997년에는 HTTP/1.1, 2015년에는 HTTP/2, 2022년에는 HTTP/3이 생겨나기 시작했다. HTTP를 만들게 된 이유는 이 또한 역시 CERN에서 문서를 찾기 어려운 상황에서 흩어진 문서를 링크를 통해서 가져오기 쉽게 만들기 위함이였고 HTML이 있어도 이를 어떻게 쉽게 연결할 수 있을까 하는 고민지점에서 생겨나게 되었으며 어떻게 요청하고 어떻게 받을 것인가에 대한 규칙이 없으면 연결하기 어려움이 있다고 판단하여 만들게 되었다. 설계 방향은 더욱 간단하게, 많은 사람이 쉽게 읽을 수 있는 컴퓨터 용어가 아닌 텍스트로, 요청과 응답을 단순하게 하여 클라이언트가 요청하면 서버가 응답하는 식으로 만들어졌다. 마지막으로 기존에 넓게 펴져있던 네트워크 위에 얹어 새 네트워크를 구축하지 않아도 간편히 사용할 수 있게 도왔다.

ㄴHTTP가 년도에 따라서 업그레이드가 되었는데 어느부분이 어떻게 좋아진거야?

HTTP/0.9 - 단순 HTML만 넘겨주었고 이미지나 영상은 넘겨주기 어려웠으며, 발송이 성공했는지 실패했는지를 알 수 없었다.

HTTP/1.0 - 헤더가 생겨나면서 각 문서가 어떤것은 텍스트이고 어떤것은 이미지인지 구체화를 도왔으며, 상태코드가 생겨나 문서의 발송 성공과 실패를 더 확실히 알 수 있게 되었다. 다음으로는 메서드가 더 생겨나면서 이미지등 다른 데이터를 보내는데도 더욱 쉬워졌다. 하지만 연결을 돕고 다음 질문을 하면 그 연결을 끊고 다시 연결을 시도하는 방식으로 설계되어 있어서 너무 오랜 시간이 걸린다는 단점이 있다.

HTTP/1.1 - HTTP/1.0에 문제였던 연결을 더욱 유연하게 수정하여 연결은 끊지 않으면서 여러 요청을 능동적으로 해결하게 되었다. 또한 한 서버에서 여러 도메인을 사용할 수 있게 되었으며, 기존의 캐시를 강화하여 재사용하는 규칙이 더욱 단단해졌다. 또한 메서드가 추가 되었고 분할전송이 생겨 크기가 크더라도 조금씩 잘라 보낼 수 있게 되었다. 그러나 또 다른 문제점이 생겼는데 한 연결에서 순서대로 처리하게 되면서 파일이 밀리게 되면 기다림이 길어졌다. 그리 하여서 한번에 많은 브라우저를 열거나 파일을 합치게 되는 현상이 나타나게 되었다.

HTTP/2.0 - HTTP/1.1에 문제였던 처리방식을 능동적으로 바꾸게 되면서 하나의 연결에서도 여러 요청을 해결하게 되었다. 또한 글자 대신 컴퓨터가 해결하기 쉬운 이진형식을 채택하여 더욱 효율이 좋아졌다. 또 헤더를 압축하게 되어 전송량이 줄어들게 되었다. 마지막으로 서버 푸시 기능으로 서버가 요청하기 전에 필요한 내용을 먼저 보내주는 기능이 생겼으나 사용하는 사람이 적어서 없어졌다. 이번에도 문제가 생겼는데 TCP특성상 패킷이 하나 유실되면 전체적으로 멈춘다는 큰 문제점이 있었다.

HTTP/3.0 - TCP대신 QUIC를 사용하게 되면서 패킷이 유실되어도 다른 방식으로 계속 진행되게 바뀌었고, 연결이 빨라졌으며, 보안 내장이 강화되었다. 마지막으로 WIFI에서 데이터로 바뀌게 되면서 IP가 바뀌게 되어도 연결은 끊지지 않게 되었다.

ㄴ 바이너리와 헤더, 메서드를 간단히 설명해줘

바이너리 - 컴퓨터가 사용하는 용어로 0과 1로 이루어짐. 사람들이 직접 읽기에는 어렵지만 컴퓨터는 0과 1로 이루어져 더욱 빠르고 오류도 적어지고 크기도 많이 줄어듦

헤더 - 요청이나 응답을 더욱 쉽게 확인할 수 있도록 알려주는 설명서로 생각하면 쉽다. 이 데이터가 이미지인지 텍스트인지, 크기는 얼마나 되는지, 어느 도메인에서 요청하는지을 알려줆

메서드 - 클라이언트가 서버에 요청하는 동작. 데이터를 가져오거나, 수정, 삭제등의 동작을 요청하는 것이라고 생각하면 됨

3. HTTP가 나오기 전에는 문서를 주고 받는 도구는 많았으나 문서의 링크가 자유롭게 오고가는 방식은 아니였다. 그 당시에 사용했던 방식은 FTP, Telnet, SMTP, NNTP, Gopher으로 5가지 정도가 있는데 FTP는 파일을 올리고 내려받는 프로토콜이고, Telnet는 컴퓨터 명령어로 직접 오더를 내리는 방식이였다. SMTP와 NNTP는 메시지로 주고 받는 형식이였으며, Gopher은 메뉴에 따라서 정보를 찾아가는 방식이였다. 모두 목적은 확실하지만 링크를 주고 받는것은 아니였다. 먼저 FTP는 지속적인 로그인을 해줘야하는 번거로움이 있어 하이퍼링크의 장점이 없어진다. 또한 FTP와 Telnet은 사용하는 동안 세션이 지속적으로 붙잡고 있어야 하는 번거로움이 있었다. 또 FTP는 내가 확인하고 있는 문서와 확인해야하는 문서를 번갈아가며 확인하기에는 문제가 있었고, 요청을 할때는 서버의 주소, 폴더 경로, 파일 이름등 직접알고 직접 하나하나 이야기 해야하는 번거로움 또한 함께 있었다. 또한 각자의 프로토콜에 맞춰서 사용법이 달랐기에 하나하나 사용법을 익혀야했다. 그리고 이것이 어떤것인지 구체적으로 알려주는 규칙이 약했던 약점도 존재했다. 마지막으로 그냥 간단하게 주고 받는 형식이 복잡하였다.

4. 이전에 비해서 요청이 훨씬 쉬워졌으며 로그인등 번거로운 작업이 최소화되었다. 또 이전처럼 서버를 하루종일 잡고 있어야하는 문제점도 줄어들었다. 또 파일에서 내려받은 후 확인해야하는 번거로움이 있었는데 이 또한 HTTP로 통일이 되며 더욱 간편히 한눈에 보기 쉬워졌다. 그리고 URL과 합쳐 파일이 링크를 타고 빠르게 전달할 수 있는 간편함 또한 생겼다. 그리고 HTTP의 방식으로 브라우저 하나로 확인이 쉬워졌다. 결과를 알려주는 부분 또한 개선 되었는데 200이나 404로 결과를 더욱 쉽게 알 수 있게 되었다. 마지막으로 누구든지 간편히 서버와 브라우저를 직접 만들기 쉬워졌다.

5. HTTP가 없던 전에는 복잡했던 절차가 간단히 요청과 응답으로 편리해졌다. 또한 서버 안에 무엇을 어디서가 다 들어있어 서버는 이전 요청을 기억할 필요 없이 서버가 응답 후 바로 도움을 줄 수 있게 되었다. 그래서 어느 서버가 요청을 받아도 이전과 같이 처리할 수 있어서 서버를 늘려 확장하기 쉬운 구조가 되었다. 또 보기와 받기의 분리를 더 명확하게 볼 수 있게 되었고, URL과 메서드가 합쳐지게 되어 브라우저를 클릭 한번으로 쉽게 이동이 가능해졌다. 또 방식이 서로가 다른 상태를 프로토콜로 통일하게 되었다. 마지막으로 구현이 복잡했던 이전과는 다르게 텍스트로 단순화 되었다.

<URL>

1. URL은 Uniform Resource Locator의 약자이다. Uniform은 '통일된'이라는 뜻인데 이전에는 각 도구의 주소마다 다른 위치에 있었는데 URL로 모든 도구의 위치를 한곳으로 통일하였다. Resource은 '자원'이라는 뜻인데 이는 각 이미지, 영상, 데이터등을 뜻하는 단어이다. 마지막으로 Locator은 '위치를 알려주는 것'이라는 뜻이다. 이는 URL에서 어느 위치에 있는지를 알려주는 단어이다. 이 3단어가 묶여서 URL이 되었으며 이를 합치게 되면 어떤 자원이든 통일되게 위치를 알려주는 주소라고 생각하면 된다. 이전에 URI, URN도 있었는데 URI는 자원의 이름을 식별하는 개념이며, URN은 URI에서 이름을 식별하는것다. 그러나 이들을 전부 URL이라고 부른다. 버너스리는 URL을 처음에는 UDI로 불렀으나 IETF에서 URL로 바꾸어 불렀다고 한다.

2. 이 또한 팀 버너스리가 설계했으며 CERN에서 웹을 만들며 구상한것이며 로이 필딩과 래리 매신터와 IETF와 같이 규격을 정리하였다. 1991~1992년 초기에 웹 문서에서 UDI형태의 주소로 실제 사용하였다. 그리고 1994년 RFC 1738로 URL의 첫 공식이 정리 되었고 같은 시기에 URI의 개면도 문서화되었다.

1998년 RFC2396으로 URI 문법이 개정되었고, 2005년 RFC 3986으로 현재의 URI가 표준으로 확장되었고 이는 지금가지도 기본으로 사용되고 있다. 실제로 웹을 작동하려면 문서에 주소를 붙여서 그 문서를 어디서든지 가리킬 수 있어야했기 때문에 HTML에 링크를 걸려면 어디에 무엇이 있는지를 확인할 방법이 필요했고, HTTP로 요청을 하려면 주소가 명확해야 하기 때문에 URL을 구상하게 되었다. 이를 설계할때는 모든 자원에 주소를 붙여 하나하나 명확히 확인할 수 있도록 하기 위함으로 설계하였고, 이전에 다영한 주소를 한번에 묶기 위함도 있었다. 또 글자로 된 주소이기에 사람들이 더욱 쉽게 읽고 쓸 수 있도록 도왔으며 마지막으로 웹이 이미 있었을때도 그 웹에서 자원을 가리켜 웹을 더 빠를게 확장하였다.

ㄴ RFC는 뭐야?

RFC는 Request for Comments의 약자로 '의견 요청서'이다. 1969년 미국의 스티브 크로커가 처음 만들었으며, 당시 인터넷의 전신인 ARPANET을 연구한던 시기였는데 연구자들이 설계 아이디어를 정리해서 돌려보던 메모에서 시작되었다. 인터넷 기술의 정보나 실험 결과를 담은 공식 문서이며, 한 번 발행되면 내용을 고치지 않는 게 원칙이며 수정이 필요하면 수정된 문서와 번호를 새로 내고 옛 문서에는 어느문서로 대체되었다고 표시했다고 한다. 이는 IETF에서 관리하며 여러 논의와 합의를 거처 RFC로 발행된다. RFC는 여러 종류가 있는데 표준 트랙 (실제 인터넷 표준이 되는 문서), 정보 (참고용 설명 문서인데 HTTP/~의 RFC~가 여기에 해당됨), 실험 (시험적 제안), 현행 모범 사례 (권장 운영 방식)등으로 여러 종류가 있다. 그래서 RFC가 있다고 바로 공식 표준이 되는것은 아니고 문서의 종류를 함께 봐야 정확히 알 수 있다.

3. URL이 나오기 이전에는 자원을 가리키던 방식에서 어려움이 있었다. 당시에 자원을 가리키던 방식으로는 여러가지가 있었는데 FTP, Telnet, 이메일, 유즈넷, Gopher이 있었다. FTP는 서버 이름과 디렉터리 경로, 파일의 이름을 각각 따로 다 알아야 했으며, Telnet은 호스트의 이름과 포트 번호를 수동으로 직접 입력해야 했으며, 이메일은 '사용자@도메인'형식의 주소를 사용했다. 유즈넷은 뉴스그룹 이름으로 가르켰으며, Gopher은 서버가 알려주는 메뉴 항목을 따라 들어가야하는 방식이였다. 각각의 방식은 있었지만 이들이 한 번에 사용되는 공통 주소는 없었다. 그리하여 서비스마다 주소를 표기하는 것이 서로 다 달랐으며, 자료의 위치를 한 번 알기 위해서는 긴 문장으로 구체화해서 설명을 해야 했다. 또한 같은 자원이라도 어느 방식으로 접근할지와 어디에 있는지가 명확히 표시되지 않아 추측으로 프로그램을 골라서 확인해야 했으며, 하이퍼텍스트의 핵심은 문서안에서 다른 문서를 가르키는 것인데 이를 기계가 직접 따라 갈 수 있는 형식이 없었다. 다음으로는 네트워크의 경로는 있었지만 전 세계 어딜가든 같은 자원을 명확히 가리키는 이름은 옅었으며, 마지막으로 새로운 서비스가 생기면 그에 맞는 주소 표기도 다시 해야하는 번거로움이 있었다.

4. URL이 나온 이후에는 이 번거로움들이 해소 되었는데 먼저 표기에 어려움을 하나의 틀로 어느 자원이든 가리킬 수 있었다. 또 긴말이 필요 없이 한 줄로 해결이 되었으며, 접근 방식이 단순화 되어 더 편리하게 사용이 가능해졌다. 다음으로는 문서 안에 링크를 걸어두어 그 링크를 이용하여 원하는 자원으로 편히 이동이 가능했고, 전세계 어디에서든 원하는 자원을 찾을 수 있게 되었다. 또 사람이 외우거나 읽기 쉬워져서 다른 사람에게 전달하기에 더욱 편리해졌고, 새로운 서비스가 생겨도 기존에 있던 틀을 조금 확장하여 더욱 쉽게 해결되었고 마지막으로 자원의 부가 정보까지 확인 할 수 있게 되어 편리하게 사용할 수 있게 되었다.

5. 이전에는 사용하는 컴퓨터나 프로그램이 달랐기에 표기를 제각각하여 맞는 프로그램을 사용하기에 어려운 번거로움이 있었지만 하나의 문법으로 통일하여 번거로움이 해결 되었다. 또 많은 설명이 필요했던 이전과는 달리 한줄이면 필요한 정보를 빠르게 전달할 수 있어 더욱 편리해졌다. 방식과 위치가 불분명했던 문제점은 스킴을 맨 앞에 고정으로 배치하여 프로토콜을 요청하기에 더욱 편리해지게 되었다. 또 URL은 문자 형태이기에 HTML 속성값에 넣을 수 있어 브라우저가 문자열을 분해하여 HTTP 요청으로 자동으로 바꾸어 자동으로 이동이 되었다. 이 부분은 HTML, URL, HTTP가 모두 사용되는 지점이라 중요한 부분이다. 다음으로는 호스트 부분에 DNS 도메인 이름을 사용하였는데 도메인은 중복 없이 관리되고 있어 도메인과 경로를 합치면 어디서든 같은 자원을 가리키는 주소가 되었다. 그리고 이전에는 확장할때 복잡한 문제가 있었지만 새 스킴을 등록하면 같은 틀로 들어와져 더 간단해졌다. 마지막으로 파일을 지정할때 한계가 있었지만 이는 쿼리와 프래그먼트가 생기면서 쿼리로 서버 조건을 전달하고 프래그먼트에서 문서 안에서 위치를 가리키게 되어 페이지나 긴 문서의 대목도 주소로 공유할 수 있게 되었다.

ㄴ 스킴, 호스트, 포트, 쿼리, 프래그먼트, DNS을 간단하게 설명해줄래?

스킴 - 어떤 방식으로 접근할지를 알려주는 부분이며, URL의 맨 앞, :앞에 오게됨

https: 암호화된 웹 통신

http: 일반 웹 통신

ftp: 파일 전송

mailto: 이메일작성

호스트 - 어느 서버에 요청할지 가리키는 부분

www.~.com이나 xx.xxx.xxx.xx 같은 IP 주소를 가리키는 부분

포트 - 서버의 다양한 번호

http의 기본 포트 : 80

https의 기본 포트 : 443

기본 포트는 평소에 생략되며 '~.com:8080' 처럼 사용됨

쿼리 - 서버 추가 조건의 값을 전달하는 부분

https://xxxxxxx.com/search?q=web&page=2

여기서 ? 뒤에는 이름=값 형태로 적히고, 여러개는 &로 잇는다.

추가 요청 사항을 전달한다고 생각하면 쉽다

프래그먼트 - 문서 안에서 특정 위치를 가리키는 부분

# 뒤에 사용됨

DNS - 도메인 이름을 IP 주소로 바꿔주는 시스템

사람은 숫자를 쉽게 외우지 못하니 우리가 영어로 지시하고 이를 받아서 IP로 변경 후 컴퓨터에 적용시켜 컴퓨터가 확인 후 처리 할 수 있도록 돕는 시스템

AI 대화 내역 링크:https://claude.ai/share/812f3eb7-d286-42ab-b716-7a88152c9cf0

오늘 잘한 점: 최대한 이해하려 노력했으며 이해가 되면 넘어가는식으로 최대한 생각하고 고민하며 공부하였다.

오늘 부족했던 점: 충분히 이해는 하였지만 생각을 담아내기보다는 읽고 쓰기에 초점이 맞춰진듯하여 아쉬움이 있다.

오늘 총평: 어제보다는 집중이 잘 되었으며 최대한 이해하려고 노력하여 많은 내용을 학습한듯하여 뿌듯하다. 그러나 아직 전문지식이 부족하여 읽고 쓰는것에 초점이 맞춰진듯한 느낌이 들어 아쉬웠다.

부족한 단어: 하이퍼링크, 링크, ENQUIRE, W3C, FTP, Usenet, Telnet, Archie, Gopher, 하이퍼텍스트, 하이퍼카드, 메멕스(Memex), 모자이크(Mosaic), link rot, 테드 넬슨, HTML Tags, 바이너리 형식, SGML, 검색 엔진, 스크린 리더, 자동 처리 도구, 로이 필딩, 헨릭 프리스틱 닐슨(Henrik Frystyk Nielsen), IETF, 인터넷 통신 방식(TCP/IP), 메서드, 데이터, Head-of-Line Blocking, 멀티플렉싱, 디렉터리

여기에 파일을 드롭하세요