-
Notifications
You must be signed in to change notification settings - Fork 0
2주차 수요일 그룹 4
HTTP의 역사를 공부하다 보니, HTTP/1.0이 아닌 HTTP/1.1을 왜 널리 사용하게 되었는지 알게 되었다. HTTP/1.1를 발표한 가장 큰 이유는, Short-lived Connections 문제이다. 매 요청/응답마다 TCP 커넥션을 맺어야 하기에 성능상 큰 손해를 보기 때문이다. 이러한 점을 알게되니, 내 WAS는 연결을 유지하고 있는 지 궁금했다. 로그를 확인해보니 /index.html로 접속했을때, index.html안에 있는 css, favicon.io등 다시 소켓을 연결하고 있다는 것을 알게 되었다. 확인 해보니, setSoTimeout()을 통해 연결 시간을 유지할 수 있었다. 이게 맞는 방식인지는 조금 더 검증이 필요하기에 다시 확인해봐야겠다.
그룹원분들 코드리뷰를 진행하다가 상대 경로로 파일 위치를 설정해주시는 코드를 보았다. 하드 코딩하기 싫어서 상대 경로를 사용했다는 이야기를 듣고, 내 코드에도 적용해봐야겠다고 생각이 들었다.
스프링이 어떻게 동작하는지에 대해 의견을 나누었는데, 매핑된 url을 확인하고, url이 없을시 static하위 디렉토리에 있는 파일을 반환하는 것을 배웠다. 스프링과 톰캣을 공부해봐야겠다.
오늘 한 주의 중간인데 오르막은 다 지났으니, 편하게 내리막 즐기셨으면 좋겠습니다! 남은 목,금도 화이팅!
- 최대한 스프링부트 내부구조와 비슷하게 짜보려는 목적이 있습니다.
- 리팩토링을 앞둔 상태라 다른 분들의 코드를 보고 참조할 만한 점들이 많아 좋았습니다.
- 파일 경로를 getClass() 를 이용해 가져오기가 인상적이라 사용해볼 생각입니다.
- http 버전별 특징(1.1의 keep alive)을 구현하시려는 분을 보고 저도 한번 해 볼까 생각이 들었습니다.
- not found, redirect 같이 단순 200 응답 외의 기능들을 구현하신분도 있으셔서 져도 해볼 생각입니다.
- response body가 아직 요구사항이 아닌데 구현하신 분들이 계셨습니다. 객체를 json string 으로 변환하시는거 까지는 아직 생각하지 않으신것 같습니다.
- 오브젝트 책을 읽고 적용해 보려고 하신 분을 보고, 져도 책을 빨리 읽어서 적용해보고 싶다 생각했습니다.
이번에 시도하고 있는 것은 객체의 변경의 이유를 하나만 존재하게 하라입니다. 예를들어 파싱하는 paser 클래스는 헤더를 파싱하고, 바디를 파싱하고, 쿼리스트링을 파싱하는 등의 여러 변경의 이유가 존재했습니다. 따라서 해당 클래스에서 별도의 header parser, body parser등으로 분리를 하니 헤더 파싱에 변경이 있으면 header parser를 변경하면 되는 등의 응집이 잘 된 것같습니다. 그런데 이렇게 했더니 나오는 문제들 또한 존재했습니다. 우선 HTTP parser가 다른 모든 파서들을 참조하고 있다는 겁니다. 의존성이 높아진거겠죠. 또한 너무 과도한 분리는 오히려 가독성을 떨어뜨린다는 느낌이 들었습니다. 적절한 타협이 필요한 것 같습니다.
keep-alive keepalive에 대한 고민을 하고 계셨는데 확실히 1.1부터는 keepalive가 디폴트인데 같은 반복해서 요청이 들어왔을때마다 연결이 맺어지는건 문제가 있는 것 같아요. 제것도 그럴텐데 수정을 고민해봐야 겠습니다.
그리고 저는 REST API의 요청이 올 수 있다고 생각 안하고 정적 파일의 요청만을 고려했는데 rest api와 정적 요청을 구분해서 처리할 방법을 생각해 수정해야 겠습니다.
현재 별도의 경로 처리를 그냥 startwith로 하고 있는데 각각의 핸들러를 만들어 별도로 처리하는 방식이 인상깊었습니다. 그런데 이렇게 경로마다 핸들러를 생성해주면 너무 많아질거같기도 하고 다른 것들을 좀 찾아봐야겠습니다.
- 파일 경로를 class loader를 통해 불러오면은 빌드 이후에 생기는 상대적인 경로로 접근할 수 있어 안전할 것 같다고 느꼈습니다. 한번 찾아봐야겠습니다.
- HTTP 1.1의 주요특징 중에 하나인 KeepAlive를 시도해 보신 분이 계셔서 '나도 이러한 부분을 한번 해볼까?'하는 생각이 들었고 찾아보면 좋겠다는 생각이 들었습니다.
- File에서 join을 통해 다른 파일을 참조할 수 있다는 걸 알았습니다.
- Router 등을 둬서 경로를 별도로 관리하는 방법도 좋은 것 같습니다. 이런 느낌을 고민하면 좋을 것같아요.
- Handler나 Filter 등을 통해 각 행위세트?별로 수행할 일들을 분리해두는 것도 좋겠다는 생각이 들었습니다. 앞으로 여러가지 추가될게 많을 것 같고, 다른 분들에 비해 제 구조는 그런 변화에 좀 더 닫혀있다고 생각이 들었습니다.
- 지난 주 보다 구조나 흐름이 크게 다르지 않은 것 같아서 디테일을 조금 더 신경쓰면서 해야겠다고 느꼈습니다.
- 역시 다른분들의 코드를 보고 이야기하는 것은 정말 큰 도움이 되는 것 같습니다. :) 아주좋아용
File을 읽어오는 방식은 fileReader로 읽어오는 방식이 TDD를 하기에도 수월하고 좋은 것 같음. 현종씨의 코드를 보고 인사이트를 얻었음 그리고 확실히 tomcat이 하던 방식대로 핸들러로 설정을 하는 것이 좋을 것 같다. 스프링은 실제로 static handler를 따로 배치하는 방식을 사용한다. 전반적으로 설계는 사람들끼리 비슷비슷한 것 같다. 확실히 이야기하면서 많이 배운다. 특히 이번 미션은 힘들어도 열의를 가지고하니 남들이 이야기하는 구조도 눈에 쏙쏙들어온다